List of Archived Posts

2013 Newsgroup Postings (02/25 - 03/14)

NBC's website hacked with malware
Spacewar! on S/360
Legal Lessons from PATCO Fraud Case
How to Cut Megabanks Down to Size
You Call This an Army? The Terrifying Shortage of U.S. Cyberwarriors
How to Cut Megabanks Down to Size
More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
LIBOR: Viewing the Biggest Financial Crime in History
OT: CPL on LCM systems [was Re: COBOL will outlive us all]
The Strange Beauty of Historic Computers Brought Back From the Dead
OT: CPL on LCM systems [was Re: COBOL will outlive us all]
Article for the boss: COBOL will outlive us all
How to Cut Megabanks Down to Size
I do not understand S0C6 on CDSG
What Makes an Architecture Bizarre?
I do not understand S0C6 on CDSG
A Matter of Mindset: Iraq, Sequestration and the U.S. Army
I do not understand S0C6 on CDSG
WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
How to Cut Megabanks Down to Size
Ethernet at 40: Its daddy reveals its turbulent youth
A Matter of Mindset: Iraq, Sequestration and the U.S. Army
Lisp machines, was What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
REFRPROT History Question
REFRPROT History Question
What Makes an Architecture Bizarre?
The United States is leaking 1TB of data daily to foreign countries
What Makes an Architecture Bizarre?
Lisp machines, was What Makes an Architecture Bizarre?
PDP-10 byte instructions, was What Makes an Architecture Bizarre?
Russia to buy no more foreign drones
NPC Luncheon with Thomas Drake, NSA Whistleblower
30 years of PCWorld, 30 pivotal moments in PC history
Danger as stock-market "Greedometer" flashes red
How to Cut Megabanks Down to Size
More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
Lisp machines, was What Makes an Architecture Bizarre?
A Matter of Mindset: Iraq, Sequestration and the U.S. Army
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
NBC's website hacked with malware
How to Cut Megabanks Down to Size
What Makes an Architecture Bizarre?
Article for the boss: COBOL will outlive us all
More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
Why Intel can't retire X86
Why Intel can't retire X86
How to Cut Megabanks Down to Size
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
NBC's website hacked with malware
What Makes an Architecture Bizarre?
How to Cut Megabanks Down to Size
relative speeds, was What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
Still not convinced about the superiority of mainframe security vs distributed?
relative speeds, was What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
Still not convinced about the superiority of mainframe security vs distributed?
Still not convinced about the superiority of mainframe security vs distributed?
Still not convinced about the superiority of mainframe security vs distributed?
Retailer Sues Visa Over $13 Million "Fine" for Being Hacked
What Makes an Architecture Bizarre?
What Makes an Architecture Bizarre?
Digital Certificates Hide Malware
A Matter of Mindset: Iraq, Sequestration and the U.S. Army
Not the Navy's Favorite Artist Rendering
What Makes an Architecture Bizarre?
relative mainframe speeds, was What Makes an Architecture Bizarre?
Query for Destination z article -- mainframes back to the future
What Makes an Architecture Bizarre?

NBC's website hacked with malware

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NBC's website hacked with malware
Newsgroups: alt.folklore.computers
Date: Mon, 25 Feb 2013 09:43:02 -0500
re:
https://www.garlic.com/~lynn/2013b.html#63 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013b.html#67 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013b.html#68 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013b.html#69 NBC's website hacked with malware

You Call This an Army? The Terrifying Shortage of U.S. Cyberwarriors
http://news.yahoo.com/call-army-terrifying-shortage-u-cyberwarriors-060002688--politics.html

--
virtualization experience starting Jan1968, online at home since Mar1970

Spacewar! on S/360

From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Spacewar! on S/360
Newsgroups: bit.listserv.ibm-main
Date: 25 Feb 2013 08:04:49 -0800
lynn@GARLIC.COM (Anne & Lynn Wheeler) writes:
VNET wiki reference
https://en.wikipedia.org/wiki/IBM_VNET

misc. past posts mentioning internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet


re:
https://www.garlic.com/~lynn/2013b.html#7 Spacewar! on S/360

warning: vnet topic drift.

JES2 had inherited some networking support from HASP that had "TUCC" identifier in the source statements. It used spare entries in the (255 entry) psuedo spool device table ... for network definitions ... typically able to define 160 or so entries. However, 23Jun69 unbundling announcement started to charge for application software (company did make the case that kernel software would still be free).
https://www.garlic.com/~lynn/submain.html#unbundle

JES2 had fairly heavyweight development and pricing policies required that monthly price cover the ongoing costs plus the upfront development costs. Even with inherited lot of networking support from university hasp ... there was no forecasted price for JES2 networking that covered its cost (company normally did three forecast levels, high, medium, and low ... assumption was that number of customers increased as price went down ... but there was no price times number of customers ... that covered the upfront JES networking costs).

VNET had modern layered architecture (compared to JES and other of the period) ... had no limit on nodes and also could support "drivers" that talked to other infrastructures. At the time, the internal network had more nodes than could be defined in JES ... so the basis for the internal network was all VNET ... but VNET did have drivers that could talk to JES as boundary nodes (JES couldn't be trusted at other than boundary ... since it would trash traffic if either the origin or destination node wasn't in its table ... even at boundary, JES would trash traffic where that JES was the destination ... if the originating node wasn't in its table). JES lack of clean layered architecture also resulted in traffic between two JES systems at different versions would crash the MVS system. This became increasingly common as the internal network started to pass 1000 nodes world-wide. As a result, protocol conversion routines were added to the VNET JES drivers ... which would convert from any JES format to the specific format required by the specific JES version that it was directly talking to.

This
https://en.wikipedia.org/wiki/IBM_VNET

makes mentioned of 19.2kbit trans-atlantic satellite circuit. This contributed to the infamous case of traffic from San Jose JES system crashing Hursley MVS systems (because the releases were at different level). The crashes was blamed on the Hursley VNET system ... because they had failed to start the correct JES driver that converted to the format required by the Hursley JES release.

In any case, this was after the FS failure and the mad rush to get products into the 370 pipeline
https://www.garlic.com/~lynn/submain.html#futuresys

... as well as POK convincing corporate to kill the vm370 product, shutdown the burlington mall vm370 development group and transfer all the people to POK for MVS/XA (or otherwise MVS/XA wouldn't meet ship schedule nearly 7-8yrs later; Endicott managed to save the vm370 product mission, but had to reconstitute a development group from scratch ... online share archives has things to say about vm370 product code quality during the period). As a result, corporate wasn't approving the announcement and release of VNET as customer product.

The JES group finally convinced corporate to allow VNET release/announce as part of a pricing gimick ... it would be announced as a combined JES+VNET product ... where JES & VNET were both priced the same (little obfuscation since VNET did have JES drivers). Then the combined JES+VNET forecast times the price was finally larger than the JES development costs (VNET costs being nearly negligible) ... as an aside, this wasn't the only time that the slight-of-hand happened using vm370 products to cover MVS product costs. misc. past posts mentioning hasp, jes, nji, etc
https://www.garlic.com/~lynn/submain.html#hasp

besides the story here about Edson talking to ARPA
https://en.wikipedia.org/wiki/Edson_Hendricks

the internal network was larger than the arpanet/internet from just about the beginning until sometime late 85 or early 86. I've pontificated it was partially because vnet had layered implementation with effectively ability for gateway in every node ... something that the internet didn't get until the great cutover to tcp/ip on 1Jan1983 (at the time arpanet was approx. 100 nodes and 250 hosts, while the internal network was rapidly approching 1000 ... which it passed that summer). again, past posts mentioning internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet
post with copy of vnet 1000 node announcement
https://www.garlic.com/~lynn/2006k.html#3
and
https://www.garlic.com/~lynn/2006k.html#8

above also includes other weekly new node announcements during 1983 as well as summary of all internal locations that had new nodes added during 1983. There were also posters and desk ornaments as part of the 1000 node event ... picture here
https://www.garlic.com/~lynn/lhwemail.html#oldpicts

one of the major reasons for number of internet nodes passing internal network ... was PCs and workstations appearing as internet nodes ... while the communication group was in its battle to restrict workstations and PCs to terminal emulation (doing its best to fight off distributed and client/server computing). misc. past posts
https://www.garlic.com/~lynn/subnetwork.html#emulation

--
virtualization experience starting Jan1968, online at home since Mar1970

Legal Lessons from PATCO Fraud Case

Refed: **, - **, - **, - **
From: lynn@garlic.com
Subject: Legal Lessons from PATCO Fraud Case
Date: 25 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
Legal Lessons from PATCO Fraud Case
http://www.bankinfosecurity.com/interviews/legal-lessons-from-patco-fraud-case-i-1803

note that we were called in as consultants to small client/server startup that wanted to do payment transactions on their server, they had also invented this technology called "SSL" they wanted to use; it is now frequently called "electronic commerce".

As part of the effort we had to map the "SSL" technology to the payment business process as well as do walk through of the various "SSL" processes and operations (including institutions manufacturing "SSL" digital certificates). We had a number of requirements for deployment and use ... some of which were almost immediately violated ... giving rise to many of the exploits that continue to plague us to this day.

Then (somewhat because of having worked on electronic commerce), in the mid-90s, we were invited to participate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments (aka *ALL*, internet, point-of-sale, attended, unattended, face-to-face, etc)

Also there were some number of conferences in the 1995 time-frame where the consumer dialup online banking made presentations about moving to the internet ... in large part to eliminate the significant consumer support costs from proprietary dialup online operations. However, at the same time the cash management/commercial dialup online banking operations said that they would never move to the internet because of a long list of security exposures ... which have accounted for a majority of the exploits that have been seen since that time (and yes, for what ever reason, the cash-management/commercial dialup online operations also did eventually move to the internet).

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 25 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
Big Bank Welfare Queens Unprofitable Without Government Subsidies, So Why Don't We Regulate Them Like Utilities?
http://www.nakedcapitalism.com/2013/02/big-bank-welfare-queens-unprofitable-without-government-subsidies-so-why-dont-we-regulate-them-like-utilities.html

At the time of GLBA (and repeal of Glass-Steagall), there was already data that the too-big-to-fail national banks were less efficient and less profitable than the regional banks. The rhetoric on the floor of congress at the time of GLBA was its primary purpose was if you already had a bank charter, you got to keep the charter ... but if you didn't have charter you couldn't get one ... aka limit competition. In addition, GLBA repealed Glass-Steagall allowed the big too-big-to-fail to get into other lines of business (while keeping other businesses from competing with the TBTF).

At the time of GLBA, there was fear that new technologies would enable new entries into banking that would cut the cost of business by 90% ... making it profitable to offer services to the large unbanked population in the country ... and then move up the value chain taking over the rest of the market (aka reference during GLBA to keeping such operations from getting banking charters).

Why Should Taxpayers Give Big Banks $83 Billion a Year?
http://www.bloomberg.com/news/2013-02-20/why-should-taxpayers-give-big-banks-83-billion-a-year-.html

Lords of Disorder: Billions for Wall Street, Sacrifice for Everyone Else
http://truth-out.org/opinion/item/14884-lords-of-disorder-billions-for-wall-street-sacrifice-for-everyone-else

recent posts mentioning GLBA &/or Glass-Steagall:
https://www.garlic.com/~lynn/2013.html#4 HSBC's Settlement Leaves Us In A Scary Place
https://www.garlic.com/~lynn/2013.html#21 AIG may join bailout lawsuit against U.S. government
https://www.garlic.com/~lynn/2013.html#23 AIG may join bailout lawsuit against U.S. government
https://www.garlic.com/~lynn/2013.html#42 Professor Coffee Hits a Nerve at SEC
https://www.garlic.com/~lynn/2013.html#44 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#49 Insider Fraud: What to Monitor
https://www.garlic.com/~lynn/2013.html#51 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#62 Taleb On "Skin In The Game" And His Disdain For Public Intellectuals
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#30 Email Trails Show Bankers Behaving Badly
https://www.garlic.com/~lynn/2013b.html#35 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#38 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#41 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#76 Capitalism is so broken it can't be fixed Commentary: Saving capitalism will not save America

--
virtualization experience starting Jan1968, online at home since Mar1970

You Call This an Army? The Terrifying Shortage of U.S. Cyberwarriors

From: lynn@garlic.com
Subject: You Call This an Army? The Terrifying Shortage of U.S. Cyberwarriors
Date: 25 Feb 2013
Blog: Google+
re:
https://plus.google.com/u/0/102794881687002297268/posts/XqjeRYyyK9b

You Call This an Army? The Terrifying Shortage of U.S. Cyberwarriors
http://news.yahoo.com/call-army-terrifying-shortage-u-cyberwarriors-060002688--politics.html

U.S. House Intelligence Chairman: America Is Losing The Global Cyber War To China
http://warnewsupdates.blogspot.com/2013/02/us-house-intelligence-chairman-america.html
House Intelligence Chairman: U.S. 'Losing' Cyber War
http://blogs.wsj.com/chinarealtime/2013/02/25/house-intelligence-chairman-u-s-losing-cyber-war/
House Intel Chair Mike Rogers Calls Chinese Cyber Attacks 'Unprecedented'
http://abcnews.go.com/blogs/politics/2013/02/house-intel-chair-mike-rogers-calls-chinese-cyber-attacks-unprecedented/

recent posts on this theme:
https://www.garlic.com/~lynn/2013b.html#62 America Is Basically Helpless Against The Chinese Hackers
https://www.garlic.com/~lynn/2013b.html#63 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013b.html#67 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013b.html#68 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013b.html#69 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013c.html#0 NBC's website hacked with malware

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 26 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
Jack Lew's Golden Parachute; His Citigroup contract paid him a bonus for returning to government.
http://online.wsj.com/article/SB10001424127887323384604578324442830547044.html

Citi's Odd Bonus Payment to Jack Lew
http://www.motherjones.com/kevin-drum/2013/02/citis-odd-bonus-payment-jack-lew

Jack Lew's Grotesque Citi Employment Deal and the Institutionalization of Corruption
http://www.nakedcapitalism.com/2013/02/jack-lews-grotesque-citi-employment-deal-and-the-institutionalization-of-corruption.html

recent related posts:
https://www.garlic.com/~lynn/2013.html#62 Taleb On "Skin In The Game" And His Disdain For Public Intellectuals
https://www.garlic.com/~lynn/2013b.html#1 Libor Lies Revealed in Rigging of $300 Trillion Benchmark
https://www.garlic.com/~lynn/2013b.html#28 Neil Barofsky: Geithner Doctrine Lives on in Libor Scandal
https://www.garlic.com/~lynn/2013b.html#30 Email Trails Show Bankers Behaving Badly
https://www.garlic.com/~lynn/2013b.html#35 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#38 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#44 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#46 Bankers Who Made Millions In Housing Boom Misled Investors: Study
https://www.garlic.com/~lynn/2013b.html#49 Bankers Who Made Millions In Housing Boom Misled Investors: Study
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013b.html#76 Capitalism is so broken it can't be fixed Commentary: Saving capitalism will not save America

past posts in this thread:
https://www.garlic.com/~lynn/2013.html#44 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#51 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#57 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#66 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#48 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#65 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#74 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
Date: 26 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
Having No Idea What Really Happened in Foreclosure Reviews, OCC Parrots "Independent" Consultant Howlers
http://www.nakedcapitalism.com/2013/02/quelle-surprise-having-no-idea-what-really-happened-in-foreclosure-reviews-occ-parrots-independent-consultant-howlers.html

other recent whistleblower references
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace

Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
http://whistlewatch.org/2013/02/former-top-federal-whistleblower-protector-scott-bloch-esq-pleads-guilty-to-destruction-of-government-property/
New Movie Investigates the War on Whistleblowers
http://www.pogo.org/blog/2013/02/new-movie-investigates-the-war-on-whistleblowers.html

past posts in this thread:
https://www.garlic.com/~lynn/2013.html#41 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#16 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#27 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#36 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#47 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#64 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

--
virtualization experience starting Jan1968, online at home since Mar1970

LIBOR: Viewing the Biggest Financial Crime in History

Refed: **, - **, - **
From: lynn@garlic.com
Subject: LIBOR: Viewing the Biggest Financial Crime in History
Date: 26 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
LIBOR: Viewing the Biggest Financial Crime in History
http://www.counterpunch.org/2013/02/26/libor-viewing-the-biggest-financial-crime-in-history/

past posts mentioning LIBOR:
https://www.garlic.com/~lynn/2012i.html#76 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012i.html#77 'Inexperienced' RBS tech operative's blunder led to banking meltdown
https://www.garlic.com/~lynn/2012i.html#85 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012i.html#87 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012i.html#92 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012i.html#94 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012j.html#4 Interesting News Article
https://www.garlic.com/~lynn/2012j.html#15 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012j.html#19 Monopoly/ Cartons of Punch Cards
https://www.garlic.com/~lynn/2012j.html#25 This Is The Wall Street Scandal Of All Scandals
https://www.garlic.com/~lynn/2012j.html#37 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012j.html#49 Naked emperors, holy cows and Libor
https://www.garlic.com/~lynn/2012p.html#39 UBS Faces Potential LIBOR Fine Of $1 Billion -- Twice What Barclays Paid
https://www.garlic.com/~lynn/2012p.html#48 Search Google, 1960:s-style
https://www.garlic.com/~lynn/2012p.html#54 UBS Faces Potential LIBOR Fine Of $1 Billion -- Twice What Barclays Paid
https://www.garlic.com/~lynn/2012p.html#55 Search Google, 1960:s-style
https://www.garlic.com/~lynn/2012p.html#62 Search Google, 1960:s-style
https://www.garlic.com/~lynn/2013.html#4 HSBC's Settlement Leaves Us In A Scary Place
https://www.garlic.com/~lynn/2013.html#35 Does the UK Government Really Want us to Report Fraud?
https://www.garlic.com/~lynn/2013b.html#1 Libor Lies Revealed in Rigging of $300 Trillion Benchmark
https://www.garlic.com/~lynn/2013b.html#4 Libor Lies Revealed in Rigging of $300 Trillion Benchmark
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#28 Neil Barofsky: Geithner Doctrine Lives on in Libor Scandal

--
virtualization experience starting Jan1968, online at home since Mar1970

OT: CPL on LCM systems [was Re: COBOL will outlive us all]

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT: CPL on LCM systems [was Re: COBOL will outlive us all]
Newsgroups: alt.folklore.computers
Date: Tue, 26 Feb 2013 11:30:39 -0500
jmfbahciv <See.above@aol.com> writes:
Right. John had performance problems. I don't know if he ever finished a project.

tropic drift & trivia ... from Melinda's VM history:
http://www.leeandmelindavarian.com/Melinda#VMHist
and
http://www.leeandmelindavarian.com/Melinda/25paper.pdf
CP Developers CMS Developers Dick Newson, manager Tom Rosato, manager Charlie Brackett Fernando Arce Larry Estelle Bob Collins Ray Grein Bob Downs Tom Heald Paul Fay Ed Murray Sharon Koblinsky John Seymour Alan Middendorf Dave Thibodeau Dick Milley Dave Tuttle Jim Sullivan Charlie Weagle Jim Walsh Clyde Wildes Bobbie Wilson Carl Young Walt Wisnowski John Xenakis

(Xenakis was the author of the COPYFILE "compiler" among other things and was known as "Captain Midnight". Tom Rosato began calling him that because Xenakis was in the habit of working all night and then leaving lists of the new features in CMS taped to his colleagues' doors where they'd find them when they got to work in the morning.)


... snip ...

The cp67/cms group had split off from the science center
https://www.garlic.com/~lynn/subtopic.html#545tech

and moved to the 3rd flr ... absorbing much of the IBM Boston Programming Center (located there). The 3rd flr group had been responsible for CPS (interactive PLI & BASIC that ran under os/360) CPS reference:
http://www.bitsavers.org/pdf/allen-babcock/cps/CPS_Progress_Report_may66.pdf

... then in part because of morph of cp67/cms to vm370/cms ... the rapidly expanding group outgrew the 3rd flr space and moved out to the vacated SBC building at Burlington Mall (SBC having been transferred to CDC as part of some legal settlement).

I've mentioned before that with the failure of Future System effort
https://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get stuff back into the 370 product pipelines (hardware & software). The head of POK also managed to convince corporate to kill vm370, shutdown the Burlington group and move all the people to POK (or otherwise MVS/XA wouldn't ship on schedule some 7-8 yrs later) ... Endicott managed to save the vm370 product mission but had to reconstitute a group from scratch.

There was a strategy to not inform the Burlington group of the shutdown and move, until the last possible moment (in order to minimize the number of people that might escape). However, the rumor of the shutdown managed to leak ... and some number of people managed to escape the move (joke that head of POK was one of the largest contributors to vax/vms). The last couple of months at Burlington there was witch hunt to find out who leaked the information (fortunately for me, nobody gave up the person responsible).

--
virtualization experience starting Jan1968, online at home since Mar1970

The Strange Beauty of Historic Computers Brought Back From the Dead

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: The Strange Beauty of Historic Computers Brought Back From the Dead
Newsgroups: alt.folklore.computers
Date: Wed, 27 Feb 2013 10:12:33 -0500
The Strange Beauty of Historic Computers Brought Back From the Dead
http://www.wired.com/wiredenterprise/2013/02/restorations-2/

from above:
This is the "1401 Room" on the first floor of the Computer History Museum in Mountain View, California -- the room where Robert Garner and his motley crew of amateur technicians have spent the last decade reviving two of the massive IBM 1401 mainframe computers that littered the business world throughout the '60s and on into '70s.

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

OT: CPL on LCM systems [was Re: COBOL will outlive us all]

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT: CPL on LCM systems [was Re: COBOL will outlive us all]
Newsgroups: alt.folklore.computers
Date: Wed, 27 Feb 2013 10:23:18 -0500
re:
https://www.garlic.com/~lynn/2013c.html#8 OT: CPL on LCM systems [was Re: COBOL will outlive us all]

other trivia ... at the time, the cp67/vm370 group took over the 3rd flr and boston programming center ... part of 3rd flr group Nat Rochester
https://en.wikipedia.org/wiki/Nathaniel_Rochester_%28computer_scientist%29

Jean Sammet
https://en.wikipedia.org/wiki/Jean_E._Sammet
and
http://www.computer.org/portal/web/awards/sammet

from above:
She joined IBM in 1961 to organize and manage the Boston Programming Center. She initiated the concept, and directed the development, of the first FORMAC (FORmula MAnipulation Compiler. (FORMAC was the first widely used general language and system for manipulating nonnumeric algebraic expressions.)

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

Article for the boss: COBOL will outlive us all

Refed: **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Article for the boss: COBOL will outlive us all
Newsgroups: bit.listserv.ibm-main
Date: 27 Feb 2013 08:41:37 -0800
cobol trivia in a.f.c. posts about cp67 group splitting off from the science center (on the 4th flr) and moving to the 3rd flr, absorbing the boston programming group (on its way to morphing into vm370):
https://www.garlic.com/~lynn/2013c.html#8 OT: CPL on LCM systems [was Re: COBOL will outlive us all]
https://www.garlic.com/~lynn/2013c.html#10 OT: CPL on LCM systems [was Re: COBOL will outlive us all]

Jean Sammet
https://en.wikipedia.org/wiki/Jean_E._Sammet

from above:
Sammet was employed by Sperry Gyroscope from 1955 to 1958 where she supervised the first scientific programming group. From 1958 to 1961, she worked for Sylvania as a staff consultant for programming research and a member of the original COBOL group

... snip ...

http://www.computer.org/portal/web/awards/sammet

from above:
She joined IBM in 1961 to organize and manage the Boston Programming Center. She initiated the concept, and directed the development, of the first FORMAC (FORmula MAnipulation Compiler. (FORMAC was the first widely used general language and system for manipulating nonnumeric algebraic expressions.)

... snip ...

other recent posts on the subject:
https://www.garlic.com/~lynn/2013b.html#42 COBOL will outlive us all
https://www.garlic.com/~lynn/2013b.html#43 Article for the boss: COBOL will outlive us all
https://www.garlic.com/~lynn/2013b.html#45 Article for the boss: COBOL will outlive us all
https://www.garlic.com/~lynn/2013b.html#51 Article for the boss: COBOL will outlive us all
https://www.garlic.com/~lynn/2013b.html#52 Article for the boss: COBOL will outlive us all

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 27 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
re:
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size

Somewhat along the lines that at the time, the claims where the major purpose of GLBA was not the repeal Glass-Steagall ... but to restrict banking competition & new banking charters ... blocking new players leveraging significantly more efficient technologies

Thirty Years of Financial Inefficiency
http://www.nakedcapitalism.com/2013/02/thirty-years-of-financial-inefficiency.html

references

The Quiet Coup
http://www.theatlantic.com/magazine/archive/2009/05/the-quiet-coup/307364/

Bernanke tells Warren too big to fail banks "will voluntarily reduce their size"
http://www.rawstory.com/rs/2013/02/27/bernanke-tells-warren-too-big-to-fail-banks-will-voluntarily-reduce-their-size/
Monetary Policy and the Economy
http://www.c-spanvideo.org/program/311156-1
Video of Ben Bernanke Lying to Elizabeth Warren in Senate Monetary Hearings
http://johnhively.wordpress.com/2013/02/27/video-of-ben-bernanke-lying-to-elizabeth-warren-in-senate-monetary-hearings/

other posts in this thread:
https://www.garlic.com/~lynn/2013.html#44 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#51 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#57 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#66 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#48 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#65 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#74 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#5 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

I do not understand S0C6 on CDSG

Refed: **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: I do not understand S0C6 on CDSG
Newsgroups: bit.listserv.ibm-main
Date: 28 Feb 2013 08:44:59 -0800
shmuel+gen@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
The S/370 supported both 2 KiB and 4 KiB pages; the 360/67 only supported 4 KiB. As I recall, DOS/VS and OS/VS1 used 2 KiB, while OS/VS2 used 4 KiB. I don't recall what page sizes Virtual Machine Facility/370 supported.

360/67 support 4kbyte pages and 1mbyte segments ... but it also supported 24bit and 32bit virtual addressing modes (aka 16mbyte and 4gbyte virtual address spaces).

370 support 2kbyte and 4kbyte pages and 64kbyte and 1mbyte segments ... but only 16mbyte virtual address sapce.

cp67 was modified to provide 370 virtual address spaces ... supporting all the 370 option combinations ... it had "shadow tables" that emulated the various 370 options (using the rules defined for the hardware TLB, table lookaside buffer) ... which mapped the 370 virtual machine virtual address spaces (2k&4k pages, 64k&1m segments) to the 370 virtual machine space. This was in regular use on 360/67 a year before the first 370 hardware engineering machine was operational with hardware virtual memory support.

basically vm370 adopted the cp67 shadow table approach ... but mapped to 370 hardware tables instead of mapped to 360/67 hardware tables.

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Thu, 28 Feb 2013 14:00:42 -0500
nmm1 writes:
So did (many? most?) of the System/360 (and System/370?) series. Rumour has it that they had to fix the architecture before IBM Galactic Headquarters took a decision to go with EBCDIC, and it never had any firmware (let alone software) written to go with it. Nobody knew what would happen if you turned it on :-)

recent discussion of 360 ascii in mainframe mailing list
https://www.garlic.com/~lynn/2013b.html#72 One reasonf or monocase was Re: Dualcase vs monocase
https://www.garlic.com/~lynn/2013b.html#73 One reasonf or monocase was Re: Dualcase vs monocase

"The Biggest Computer Goof Ever":
https://web.archive.org/web/20180513184025/http://www.bobbemer.com/P-BIT.HTM

from above:
I mention this because it is a classic software mistake. IBM was going to announce the 360 in 1964 April as an ASCII machine, but their printers and punches were not ready to handle ASCII, and IBM just HAD to announce. So T.V. Learson (my boss's boss) decided to do both, as IBM had a store of spendable money. They put in the P-bit. Set one way, it ran in EBCDIC. Set the other way, it ran in ASCII.

But nobody told the programmers, like a Chinese Army in numbers! They spent this huge amount of money to make software in which EBCDIC encodings were used in the logic. Reverse the P-bit, to work in ASCII, and it died. And they just could not spend that much money again to redo it.


.... snip ... and (one of the Consequences):
Although some IBM customers would stay with all upper case for a while, the introduction of lower case would destroy all collating precedent, and IBM knew that, too. Especially from the STRETCH design in 1958, where I made a big mistake in setting the collating sequence as "A-a-B-b-C ..." [2]. Ordering alphabetically in dual case must be a two-step process -- first on the letter itself, and then on the quality of the letter (its case).

... snip ...

IBM ASCII reference also mentions getting collating sequence wrong in STRETCH

--
virtualization experience starting Jan1968, online at home since Mar1970

I do not understand S0C6 on CDSG

Refed: **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: I do not understand S0C6 on CDSG
Newsgroups: bit.listserv.ibm-main
Date: 28 Feb 2013 10:56:01 -0800
lynn@GARLIC.COM (Anne & Lynn Wheeler) writes:
360/67 support 4kbyte pages and 1mbyte segments ... but it also supported 24bit and 32bit virtual addressing modes (aka 16mbyte and 4gbyte virtual address spaces).

370 support 2kbyte and 4kbyte pages and 64kbyte and 1mbyte segments ... but only 16mbyte virtual address sapce.

cp67 was modified to provide 370 virtual address spaces ... supporting all the 370 option combinations ... it had "shadow tables" that emulated the various 370 options (using the rules defined for the hardware TLB, table lookaside buffer) ... which mapped the 370 virtual machine virtual address spaces (2k&4k pages, 64k&1m segments) to the 370 virtual machine space. This was in regular use on 360/67 a year before the first 370 hardware engineering machine was operational with hardware virtual memory support.

basically vm370 adopted the cp67 shadow table approach ... but mapped to 370 hardware tables instead of mapped to 360/67 hardware tables.


re:
https://www.garlic.com/~lynn/2013c.html#13 I do not understand S0C6 on CDSG

2kbyte versus 4kbyte virtual pages were trade-off between efficiency between being able to pack a program into small real storage against efficiency of I/O transfer of larger blocks ... even when all the larger page might not be required.

as real storage got larger and disk i/o became more & more a bottleneck the trade-off of 2kbyte pages shifted more and more to larger page sizes.

in the wake of FS failure
https://www.garlic.com/~lynn/submain.html#futuresys

there was resumed efforts to get products back into 370 pipeline. I got roped into helping with one of these with ECPS (vm370 microcode assist) for 138/148 (follow-on to 135/145 ... faster processor, larger real storage as well as larger storage for microcode). Old post describing some of the ECPS effort in spring of 1975:
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM micrcode assist

A combination of ECPS, VS1/VM370 handshaking, larger storage, etc resulting in VS1 running faster under vm370 than on bare real machine. Part of this was VS1/VM370 handshaking layed out the VS1 virtual address space in VM370 virtual machine address space of the same size ... so VS1 never directly did its own page .... i.e. all paging activities were done by VM370 4kbytes at a time (compared to the VS1 2kbytes at a time paging).

The other issue was my page replacement algorithm in vm370 and my VM370 pathlength for doing paging operations were both significantly better than VS1 (or OS/VS2, SVS and MVS).

As part of this, Endicott attempted to convince corporate that all 138 and 148 machines should be shipped with vm370 natively installed at the factory (short of like current generation with every machine with LPAR). However, this was in the period that POK was convincing corporate to kill off the vm370 product, shutdown the vm370 development group, move all the people to POK (other otherwise POK wouldn't be able to meet the MVS/XA ship schedule in the 80s). Endicott managed to obtain the VM370 product mission but had to reconstitute a VM370 development group from scratch (and weren't able to convince corporate that vm370 ship on every Endicott machine).

In the case of OS/VS2 (both SVS and MVS) I couldn't do anything about their enormous pathlengths for paging & page i/o ... but I did try (unsuccessfully) to get them to do much better page replacement algorithms ... pointing out some very bad decisions that they were making as part of their original effort. There was one scenario with incorrect decision in page replacement living on well into MVS release cycle ... when somebody finally fixed it ... and got an award for fixing it. They then called to see if they could do something similar/award for vm370. I pointed out that I had never done it wrong since the original changes I made as undergradudate in the 60s to cp67 ... and in fact tried to prevent the OS/VS2 crowd from originally doing it wrong.

misc. past posts mentioning paging & page replacement algorithms
https://www.garlic.com/~lynn/subtopic.html#wsclock

--
virtualization experience starting Jan1968, online at home since Mar1970

A Matter of Mindset: Iraq, Sequestration and the U.S. Army

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: A Matter of Mindset: Iraq, Sequestration and the U.S. Army
Date: 28 Feb 2013
Blog: Facebook
Boyd credited with plan for desert storm ... and then there was failure to follow through

A Matter of Mindset: Iraq, Sequestration and the U.S. Army
http://nation.time.com/2013/02/26/iraq-sequestration-and-the-army/

Whole book on slanting analysis (not just military) "Merchants of Doubt"
https://www.amazon.com/Merchants-of-Doubt-ebook/dp/B003RRXXO8/

loc977-80:
The right-wing attack on detente began in the final year of the Ford administration. In 1976, opponents of detente convinced a new Central Intelligence Agency director, George H. W. Bush, to support an "independent" analysis of Soviet capabilities and intentions. The idea was promoted by the President's Foreign Intelligence Advisory Board, which counted among its members Edward Teller.

... snip ...

which carries through the 80s, 90s, and at least into the 2nd Iraqi conflict

"Merchants of Doubt" portrays core group & individuals influencing public opinion and policy with slanted/fabricated analysis on behalf of large corporate special interests (not just MICC), "National Insecurity: The Cost of American Militarism"
https://www.amazon.com/National-Insecurity-American-Militarism-ebook/dp/B00ATLNI04/

concentrates on MICC mentioning some of the same core institutions and individuals ... with only side-note about their activities on behalf of non-MICC interests.

Boyd spent a large amount of time on this subject. He commented that they spent 18 months on strategy and collecting written approval to provide Spinney cover for this 1983 "The Winds of Reform" article in time
https://web.archive.org/web/20070320170523/http://www.time.com/time/magazine/article/0,9171,953733,00.html
also
https://content.time.com/time/magazine/article/0,9171,953733,00.html

Boyd would say when SECDEF found that he couldn't put Spinney in jail, he attempted to have Boyd banned from the Pentagon (for life) as being behind the whole thing. This leads naturally into Spinney's The Domestic Roots of Perpetual War
http://chuckspinney.blogspot.com/p/domestic-roots-of-perpetual-war.html

For a little drift ... this talks about game theory, using math to find optimal solution to complex systems:
https://plus.google.com/u/0/102794881687002297268/posts/D9zMYGik1zs

Why It's Smart to Be Reckless on Wall Street
http://blogs.scientificamerican.com/guest-blog/2013/02/27/why-its-smart-to-be-reckless-on-wall-street/

law of unintended consequences was that individuals used it to maximize their benefit at the expense of their institutions, the economy and the country.

one might claim that it overflows into MICC here with Success of Failure culture
http://www.govexec.com/management/management-matters/2007/04/the-success-of-failure/24107/

note we should all host a few on March 7th in celebration of 30th anniv. of "The Winds of Reform" article. Boyd would tell the story that lead up to the article was congressional hearing the week before. DOD forces got the hearing moved to friday afternoon and the room where watergate hearing was held (about the smallest they could find) as part of trying to minimize news coverage. Supposedly Pentagon/SECDEF held damage assessment conference on Saturday and found very few references. They were apparently blind-sided when the Time magazine cover article dropped in on Monday.

It Was 30 Years Ago Today...
http://nation.time.com/2013/02/28/it-was-30-years-ago-today/

posts mentioning Boyd, Boyd's briefings, OODA-loop, etc
https://www.garlic.com/~lynn/subboyd.html

recent posts mentioning "Winds of Reform", Perpetual War, and/or Success of Failure:
https://www.garlic.com/~lynn/2013.html#26 Cultural attitudes towards failure
https://www.garlic.com/~lynn/2013.html#46 The China Threat: The MICC Pivots Obama Back to the Future
https://www.garlic.com/~lynn/2013.html#57 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#62 America Is Basically Helpless Against The Chinese Hackers
https://www.garlic.com/~lynn/2013b.html#63 NBC's website hacked with malware

--
virtualization experience starting Jan1968, online at home since Mar1970

I do not understand S0C6 on CDSG

Refed: **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: I do not understand S0C6 on CDSG
Newsgroups: bit.listserv.ibm-main
Date: 28 Feb 2013 14:02:04 -0800
re:
https://www.garlic.com/~lynn/2013c.html#13 I do not understand S0C6 on CDSG
https://www.garlic.com/~lynn/2013c.html#15 I do not understand S0C6 on CDSG

with regard to offline email regarding page replacement algorithms

When I was starting work on paging stuff as undergraduate circa 1968, there was CACM article on "Local LRU" page replacement ... about the same time I was doing Global LRU page replacement

In the 80s, a co-worker of Jim Gray at Tandem was getting a Stanford PHD that involved global LRU page replacement ... and was strongly opposed by the "local LRU" forces. Jim was aware that I had done a lot with global LRU as undergraduate in the 60s (about the same time as the "local LRU" CACM paper) ... and actually had nearly direct "local LRU" comparison to global LRU ... and wanted me to step in to the argument on behalf of global LRU PHD (the direct global LRU comparison numbers were significant better than "local LRU").

Unfortunately this was in the era that I was being blamed for computer conferencing on the internal network ... and it took nearly a year to get IBM management approval to send the responses (even tho the response was about work before I was an employee ... while still an undergraduate in the 60s). I was hoping this was because IBM management was punishing me for online computer conferencing and not because they were taking sides in the local/global LRU academic dustup (as an aside, adviser for this particular PHD went on to be president of stanford univ ... but was still having hard time prevailing against the "local LRU" forces).

past post
https://www.garlic.com/~lynn/2006w.html#46
with copy of this response (nearly year after original request)
https://www.garlic.com/~lynn/2006w.html#email821019

--
virtualization experience starting Jan1968, online at home since Mar1970

WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
Date: 28 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
http://whistlewatch.org/2013/02/former-top-federal-whistleblower-protector-scott-bloch-esq-pleads-guilty-to-destruction-of-government-property/

POGO and Partners Tell Congress Investing in OSC Pays Dividends
http://www.pogo.org/our-work/letters/2013/POGO-and-Partners-Tell-Congress-Investing-in-OSC-Pays-Dividends.html

Investing in Watchdogs: More Bang for Your Buck
http://www.pogo.org/blog/2013/02/20130228-investing-in-watchdogs-more-bang-for-your-buck.html

from above:
A small, independent federal investigative agency that yields enormous returns to taxpayers needs more resources. When Congress passed the landmark Whistleblower Protection Enhancement Act (WPEA) in November, expanding protections for federal employees who blow the whistle on government waste, fraud, abuse, and illegality, Congress also expanded the Office of Special Counsel's (OSC) role and responsibilities. As a government watchdog tasked with protecting whistleblowers, the OSC is already experiencing a dramatically increasing caseload.

... snip ...

Obama Memo Threatens Whistleblower Protections
http://www.pogo.org/blog/2013/02/obama-memo-threatens-whistleblower-protections.html

recent related posts
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013c.html#6 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

--
virtualization experience starting Jan1968, online at home since Mar1970

More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
Date: 28 Feb 2013
Blog: Financial Crime Risk, Fraud and Security
OCC Offers Lame Defense of Failure of Litigate as More Proof Emerges of its Abject Failure to Supervise Foreclosure Reviews
http://www.nakedcapitalism.com/2013/02/occ-offers-lame-defense-of-failure-of-litigate-as-more-proof-emerges-of-its-abject-failure-to-supervise-foreclosure-reviews.html

from above:
Elizabeth Warren's opening salvo in the Senate Banking Committee, when she asked assembled top officers from various banking regulators when they had last litigated a case against a financial firm, drew blank stares (the SEC, which regularly files civil suits, was able to muster an answer).

... snip ...

Occupy the SEC, Frustrated With Regulatory Defiance of Volcker Rule Implementation Requirements, Sues Fed, SEC, CFTC, FDIC and Treasury
http://www.nakedcapitalism.com/2013/02/occupy-the-sec-frustrated-with-regulatory-defiance-of-volcker-rule-implementation-requirements-sues-fed-sec-cftc-fdic-and-treasury.html

recent whistleblower related discussions in this linkedin group
https://www.garlic.com/~lynn/2013.html#41 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#16 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#27 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#36 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#47 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#64 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013c.html#6 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#18 WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Thu, 28 Feb 2013 21:36:31 -0500
Peter Flass <Peter_Flass@Yahoo.com> writes:
Yes, but this is done by the control unit (as you allude later) and the P bit has no effect on what is stored.

re:
https://www.garlic.com/~lynn/2013c.html#14 What Makes an Architecture Bizarre?

there was actually a different kind of problem involving IBM termianls and ASCII terminals.

IBM terminals weren't ebcdic ... and so terminal data had to be translated back&forth between terminal bit pattern and ebcdic bit pattern.

when cp67 was delivered to the univ, it had 1052 & 2741 terminal support (with appropriate translate tables). The univ had some number of tty/ascii terminals and I added tty/ascii terminal support and the appropriate translate tables ... the issue was that there are some chars in ascii that aren't in ebcdic as well as the reverse ... so there was some issues of mapping ascii characters (not defined in ebcdic) to something ... as well mapping some ebcdic characters (not defined in ascii) to something.

the other issue was that cp67 code as delivered did automatic terminal type identification ... and dynamically changed the terminal controller line-scanner to the appropriate one for that kind of terminal. when I added tty/ascii support ... I extended the automatic terminal type processing to include tty/ascii. I actually tried to have a single dial-in number (for all types of dialup terminals; with common hunt-group ... pool of numbers and corresponding controller port connections). it turned out that they had taken some sort cuts in the ibm terminal controller ... while it was possibly to dynamicall change the terminal type line-scanner for each controller port ... they hard-wired each port line-speed. It wasn't problem for common pool for 1052 & 2741 terminals since they operated at the same line speed ... but it was a problem for tty/ascii which operated at different line speed.

this was part of the motivation for the univ to start a clone controller project, started with interdata/3 programmed to emulate the ibm terminal controller (but supporting adapting both the port line scanner as well as the port line speed) ... as building a controller channel I/O interface board for the interdata/3 (later it evolved into an interdata/4 for the channel interface with pool of interdata/3s for handling ports). early bug was data arriving in 360 memory all garbled ... it turns out that the ibm terminal controller convention was to place the arriving leading bit in the low-order bit position in the byte and the fill the byte in reverse direction as the bits arrived ... then transmit each byte to 360 memory (so bits within byte were in reverse order of arrival). The initial testing with interdata/3 had bits in the byte in bit arrival order (not reverse order) ... aka 360 terminal standard had terminal/line ascii in bit-reversed order.

later, four of us are written up as being responsible for (some part of) ibm clone controller business. ... some past posts
https://www.garlic.com/~lynn/submain.html#360pcm

later still, the folklore is that major motivation for IBM's Future System effort (completely replace 360 with something radically different) was to make the controller interface so complex that it would be a barrier to clone controller business. misc. past posts mentioning (failed) future system
https://www.garlic.com/~lynn/submain.html#futuresys

The rise and fall of IBM
https://www.ecole.org/en/session/49-the-rise-and-fall-of-ibm

from above:
IBM tried to react by launching a major project called the 'Future System' (FS) in the early 1970's. The idea was to get so far ahead that the competition would never be able to keep up, and to have such a high level of integration that it would be impossible for competitors to follow a compatible niche strategy. However, the project failed because the objectives were too ambitious for the available technology. Many of the ideas that were developed were nevertheless adapted for later generations. Once IBM had acknowledged this failure, it launched its 'box strategy', which called for competitiveness with all the different types of compatible sub-systems.

... snip ...

actually lots of FS was pure blue sky more like vaporware

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Fri, 01 Mar 2013 08:35:46 -0500
Peter Flass <Peter_Flass@Yahoo.com> writes:
Maybe Hursley? I think most S/360 models were designed in different locations - I'd have to check Pugh to verify. I know models came out of Poughkeepsie, Endicott, Hursley, and Sindelfingen. Most of them used entirely different technologies. Back in the days before the Internet it must have been quite a challenge to keep everyone on the same page, or at least in the same book.

re:
https://www.garlic.com/~lynn/2013c.html#14 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#20 What Makes an Architecture Bizarre?

architecture "red book" ... was one of the genereal corporation documents first moved to cms script.

cms script was early port of CTSS runoff in the mid-60s.

architecture "red book" was named for red 3-ring binder that it was distributed in ... and superset of principles of operation. principles of operation was subset of the "red book" ... with engineering notes, feature justification, alternatives considered, etc. intermixed with the principles of operation.

cms script command line option would produce either the full "red book" or the principles of operation subset.

sindelfingen did get its hands slapped for its design/implemention of the 370 115/125 ... since it was much more powerful than it looked.

it had nine-position memory bus for microprocessors. the 115 all had the same microprocessors at the various memory bus locations ... controllers and processor that simualted 370 ... with different program loads for the different functions ... the processor that simulated 370 tended to avg. ten native instruction for every 370 instruction simulated ... and the 115 was rated at about 80KIPS 370 (needing 800KIPS native).

The 125 was the same as the 115 ... but the processor for 370 was faster, rated at about 100KIPS 370 (i.e. native 1mip processor).

after joining the science center, one of my hobbies was producing enhanced (virtual machine) cp67 (and later vm370) systems for internal datacenters ... which had me getting invited to all sorts of locations as part of install and operation. Remember in the early 70s getting overseas trips visiting sindelfingen, paris, london, tokyo, etc for fun of it (where the visited location paid for my T&E).

The data processing (sales & marketing) had created HONE system (originally on cp67 platform then moved to vm37) that provided online services to sales&marketing ... eventually growing to being deployed at large number of locations worldwide. When EMEA hdqtrs moved from states to Paris in the early 70s ... I was roped into going over as part of putting up HONE operation in Paris. For whatever reason, they also tried to rope me into internal EMEA politics with primary participants being English, French and Germans ... and all three trying to suck me into taking country sides. Early 70s still had lots of WW2 overtones.

misc. past posts mentioning HONE
https://www.garlic.com/~lynn/subtopic.html#hone

misc. past posts mentioning getting sucked into doing software & hardware design for 370/125 5-way multiprocessor (which never shipped) ... where five of the nine memory bus positions would have microprocessors loaded with 370 instruction set simulation.
https://www.garlic.com/~lynn/submain.html#bounce

I took the liberty of doing some special multiprocessor support design ... which turned out to not be all the different with some features that later show up in intel 432.

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Fri, 01 Mar 2013 08:53:46 -0500
re:
https://www.garlic.com/~lynn/2013c.html#14 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#20 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#21 What Makes an Architecture Bizarre?

fingerslip ... 125 was more like 120kips (not 100kips) 370 ... making the native processor approx. 1.2mips (i.e. 125 was rated at approx. 50% faster 115, at least for 370 instruction set) ... the five-way would have been aggregate over half-mip 370 ... making it serious competition with endicott machines (part of the reason it didn't get announced).

other topic drift ... recent posts in ibm-main mailing list about 370 having 2kbyte & 4kbyte pages and 64kbyte & 1mbyte segment sizes
https://www.garlic.com/~lynn/2013c.html#13 I do not understand S0C6 on CDSG
https://www.garlic.com/~lynn/2013c.html#15 I do not understand S0C6 on CDSG
https://www.garlic.com/~lynn/2013c.html#17 I do not understand S0C6 on CDSG

and some stuff about endicott 138/148 (follow-on to 135/145) and paging.

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 02 Mar 2013 10:15:57 -0500
Robert Wessel <robertwessel2@yahoo.com> writes:
One shop I worked with ordered some custom print trains (not particularly hard or expensive if you stuck with preexisting slugs), which had the entire SN set plus a couple of characters, IIRC, but only one copy of the lowercase and less common characters. OTOH, there were four repetitions of the "common" characters. That allowed modest amounts of lowercase output while still providing good speed on "normal" output. I was always a bit puzzled that IBM never provided a similar standard train.

re:
https://www.garlic.com/~lynn/2013c.html#14 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#20 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#21 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#22 What Makes an Architecture Bizarre?

Los Gatos VLSI lab did some printing of designs with block diagrams and got special/custom 1403 print train that at 8lines/inch (instead of standard 6lines/inch) printed with straight lines being continuous (both vertical and horizontal)

recently, similar thread in ibm-main mailing list about upper/lower case terminal support ... and 1403 lower-case print trains at half-speed.
https://www.garlic.com/~lynn/2013b.html#55 Dualcase vs monocase.

however, big case for full-speed 1403 bulk printing was the offline, batch paradigm where all output was 1403 print. interactive computing that tended to have upper/lower case terminals ... and more requirement for (slower) lower-case 1403 print ... tended to have increased requirement for upper/lower case printing ... but much less printing ... since much of the input/output was on the interactive terminals (i.e. with less bulk print requirement, the 1403 print speed was less of issue).

more in "dualcase vs monocase" thread:
https://www.garlic.com/~lynn/2013b.html#56 Dualcase vs monocase. Was: Article for the boss
https://www.garlic.com/~lynn/2013b.html#57 Dualcase vs monocase. Was: Article for the boss
https://www.garlic.com/~lynn/2013b.html#58 Dualcase vs monocase. Was: Article for the boss
https://www.garlic.com/~lynn/2013b.html#59 Dualcase vs monocase. Was: Article for the boss
https://www.garlic.com/~lynn/2013b.html#72 One reason for monocase was Re: Dualcase vs monocase. Was: Article for the boss
https://www.garlic.com/~lynn/2013b.html#73 One reason for monocase was Re: Dualcase vs monocase. Was: Article for the boss

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 02 Mar 2013 10:55:12 -0500
Peter Flass <Peter_Flass@Yahoo.com> writes:
Yes, Bitsavers is a wonderful resource. Looking at the green card there were "control" CCWs for the following: UCS Load (No Folding) - FB UCS Load (Folding) - F3 Block Data Check - 73 Reset Block Data Check - 7B

ios3270 "green card" (graphic representation of some, but not all, on 3270 terminal) ... quick&dirty conversion to html
https://www.garlic.com/~lynn/gcard.html#24

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 02 Mar 2013 11:24:33 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
ios3270 "green card" (graphic representation of some, but not all, on 3270 terminal) ... quick&dirty conversion to html
https://www.garlic.com/~lynn/gcard.html#24


re:
https://www.garlic.com/~lynn/2013c.html#23 What Makes an Architecture Bizarre?

ios3270 was cms application for full-screen (3270) menu applications.

while original didn't have complete green card, as noted, I sent the author the additions for device "sense" data ... that came off the 360/67 "blue card" (with addition of couple extra devices including HYPERchannel A220).

even people that might never have directly used cms ... could have been exposed to ios3270 ... since all the service processor screens on the 3090 were ios3270 (the 3090 service processor was a pair of redundant 4361s running custom modified version of vm370 release 6).

mainframe field service process required bootstrap process starting with scoping for failed process. starting with 3081 and TCMs ... it was no longer possible to use scope to diagnose failed component.

a service processor was created with diagnostic lines into the TCMs ... field service could scope diagnose a failed service processor and then use that to diagnose the rest of the machine. 3081 had UC for service processor (grossly underpower processor used also in 8100, 3705, and other places) ... which also required a completely roll-you-own environment developed from scratch.

original manager responsible for 3090 service processor ... decided that instead of doing another roll-your-own, developing something brand new from scratch ... he would build layer it on vm370/cms enviornment. started out being vm370/cms 4331 (which could be scoped/diagnose and then used to diagnose 3090) ... but later decision was to make it a pair of redundant vm370/cms 4361s. In any case, all the 3090s service processor menus were done in cms ios3270

some old email mentioning 3092 (3090 service processor)
https://www.garlic.com/~lynn/2010e.html#email861031
https://www.garlic.com/~lynn/2010e.html#email861223

I had actually provided some support to the manager of the 3090 service processor group ... but by the time of the above email, all the parties had completely changed.

the above mentions that I had done DUMPRX ... was a something I had developed to replace the standard product IPCS, dump analysis and diagnostic tool. I had done it to have ten times the performance and ten times the function of the standard product ... but for some reason it never shipped to customers, ... even tho it was in use by all the internal datacenters and most of the customer support PSRs. misc. past mentioning dumprx
https://www.garlic.com/~lynn/submain.html#dumprx

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 2 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
Fed can fix the economy
http://www.atimes.com/atimes/Global_Economy/GECON-01-270213.html

from above:
Quantitative easing (QE) is supposed to stimulate the economy by adding money to the money supply, increasing demand. But so far, it hasn't been working. Why not? Because as practiced for the last two decades, QE does not actually increase the circulating money supply. It merely cleans up the toxic balance sheets of banks. A real "helicopter drop" that puts money into the pockets of consumers and businesses has not yet been tried. Why not?

When Ben Bernanke gave his famous helicopter money speech to the Japanese in 2002, he was not yet chairman of the Federal Reserve. He said then that the government could easily reverse a deflation, just by printing money and dropping it from helicopters.


... snip ...

Wall Street's Been So Obsessed With Elizabeth Warren It Missed The Real Threat In The Senate
http://www.businessinsider.com/sherrod-brown-safe-banking-act-2013-3

part of the reasons:
We cannot rely on the financial market to fix itself because the rules of competitive markets and creative destruction do not apply to the Wall Street megabanks

... snip ...

Around the Madoff hearings and the testimony of the person that had tried unsuccessfully for a decade to get the SEC to do something about Madoff, ... news shows tried to get him for interviews ... and he always refused (not even wanting to be photographed). He finally sent a legal representative to some interviews. The story was concern that the only reason that the SEC would stonewall for a decade doing something about Madoff was that Madoff was in league with some very bad people and these very bad people (given to physical violence) also held sway over the people at SEC (and might be inclined to take retribution for the part he played) ... explaining way SEC didn't take any action.

A year later, when the person was on book tour and doing TV interviews ... he mentioned that it finally came out that Madoff had turned himself in ... apparently because Madoff may have defrauded some very bad people and was looking for government protection. However that still doesn't explain why SEC refused to take any action for a decade (Madoff turning himself in effectively finally forced SEC to take action).

His fears weren't entirely far-fetched ... nearly decade earlier with the internet bubble, there was case of investment banker being found on the new jersey mud flats.

In the too-big-to-fail there were also the risk managers at the institutions that should have been preventing lots of the activity ... and as the economy was imploding, there was finger-pointing trying to lay blame on them (or on the risk models they used). However there were various references to the business people forcing the risk departments to fiddle the inputs ... in order to change the results (aka GIGO, garbage in, garbage out).
http://bits.blogs.nytimes.com/2008/09/18/how-wall-streets-quants-lied-to-their-computers/

then there were some articles calling for risk departments being placed at corporate level so that they were less susceptible to such influence. There were also periodic articles about various people being fired when they tried to raise objections and/or warning flags (see whistleblower discussions). Also:

Subprime = Triple-A ratings? or 'How to Lie with Statistics' (gone 404 but lives on at the wayback machine)
https://web.archive.org/web/20071111031315/http://www.bloggingstocks.com/2007/07/25/subprime-triple-a-ratings-or-how-to-lie-with-statistics/

recent whistleblower discussion posts
https://www.garlic.com/~lynn/2013.html#41 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013.html#42 Professor Coffee Hits a Nerve at SEC
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#16 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#27 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#30 Email Trails Show Bankers Behaving Badly
https://www.garlic.com/~lynn/2013b.html#36 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#38 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#44 Adair Turner: A New Debt-Free Money Advocate
https://www.garlic.com/~lynn/2013b.html#46 Bankers Who Made Millions In Housing Boom Misled Investors: Study
https://www.garlic.com/~lynn/2013b.html#47 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#64 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013c.html#6 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#18 WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
https://www.garlic.com/~lynn/2013c.html#19 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

past posts in this thread:
https://www.garlic.com/~lynn/2013.html#44 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#51 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#57 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#66 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#48 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#65 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#5 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#12 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

Ethernet at 40: Its daddy reveals its turbulent youth

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Ethernet at 40: Its daddy reveals its turbulent youth
Date: 2 Mar 2013
Blog: Old Geek
re:
http://lnkd.in/xJrYGh

As periodically mentioned, the IBM internal network was larger than the arpanet/internet from just about the beginning until possibly late 85 or early 86
https://www.garlic.com/~lynn/subnetwork.html#internalnet

One of the scenarios is that the vm370 vnet networking support had something akin to a gateway in every node (as opposed to JES2 networking support which was closed infrastructure ... that limited number of nodes to about 160 and had tendency to crash MVS when two JES2 at different release levels communicated)

At the time of the great (arpanet/internet) switchover to TCP/IP on 1JAN1983, it had approx. 100 network nodes and approx. 250 connected hosts ... while the internal network was rapidly approach 1000 nodes (reached that summer; JES2 nodes had to be limited to boundary nodes because they would also trash traffic when they didn't have a definition for the destination and/or *origin* node).

Switchover to TCP/IP and internetworking support eliminated lots of restrictions to internet/arpanet growth. However, a big reason for overtaking the internal network in number of nodes, was that internally the communication group was fighting off client/server and distributed computing attempting to preserve its dumb terminal emulation paradigm and install base ... i.e. internally PCs & workstations were limited to terminal emulation while they were starting to appear as network nodes on the internet.

recent posts in thread in ibm-main mailing list mentioning inventor of internal network
https://www.garlic.com/~lynn/2013b.html#77 .
https://www.garlic.com/~lynn/2013c.html#1 .

I've periodically mentioned senior disk engineer getting talk scheduled at annual, world-wide, internal communication group conference and opened the talk with the statement that the communication group was going to be responsible for the demise of the disk division (disk division was seeing drop in disk sales with data fleeing to more distributed computing friendly platforms; disk division had come up with number of products to address the situation but were constantly vetoed since the communication group had strategic ownership of everything that crossed the datacenter walls). recent reference in ibm-main mailing list about the engineer
https://www.garlic.com/~lynn/2013b.html#57

Earlier the disk division had a project for distributed file sharing ("DataHub") ... with some amount of the software being done under work-for-hire contract with small operation in Provo, Utah (some number of students from local univ, and with people from san jose plant commuting to Provo nearly every week). Just one of the many efforts that got veto'ed and killed off ... however, one of the DataHub results was the group in Provo got to keep all the work they had developed under the contract (and shortly later there was announcement of a new company in Provo, name starts with the letter "N").

I ran an internal advanced technology conference (March1982) ... and one of the presentations was on DataHub old post on the conference
https://www.garlic.com/~lynn/96.html#4a

past posts in the thread, both in this group and other venues
https://www.garlic.com/~lynn/2013b.html#31 Ethernet at 40: Its daddy reveals its turbulent youth
https://www.garlic.com/~lynn/2013b.html#32 Ethernet at 40: Its daddy reveals its turbulent youth
https://www.garlic.com/~lynn/2013b.html#33 Ethernet at 40: Its daddy reveals its turbulent youth
https://www.garlic.com/~lynn/2013b.html#34 Ethernet at 40: Its daddy reveals its turbulent youth
https://www.garlic.com/~lynn/2013b.html#40 Ethernet at 40: Its daddy reveals its turbulent youth

--
virtualization experience starting Jan1968, online at home since Mar1970

A Matter of Mindset: Iraq, Sequestration and the U.S. Army

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: A Matter of Mindset: Iraq, Sequestration and the U.S. Army
Date: 2 Mar 2013
Blog: Facebook
is it obfuscation related to policy of perpetual war ... or true ignorance: Neo-Imperialism and the Arrogance of Ignorance
http://nation.time.com/2013/02/27/neo-imperialism-and-the-arrogance-of-ignorance/
Neo-Imperialism and the Arrogance of Ignorance
http://chuckspinney.blogspot.com/2013/02/neo-imperialism-and-arrogance-of_9705.html

Boyd had a number of stories about establishment trying to use prosecution and jail as solution to opponents. One was about the unauthorized design work he was doing for what would become the F16 (viewed as competition with the air force f15 favorite son) ... which required tens of millions of (unauthorized) gov. supercomputer time. The Sec. of Air Force was asked to prosecute Boyd for gov. theft of tens of millions (and put him away for the rest of his life) ... aka the tens of millions of unauthorized gov. supercomputer time. They investigated for three months without finding any evidence or trail leading back to Boyd, before giving up (he had anticipated the possibility and thoroughly disguised all the computer use). Having anticipated such a response from the MICC, he more than anticipated something similar over the Time article.

"National Insecurity: The Cost of American Militarism" talks a lot about MICC fabricating analysis and estimates in support of their own vested interests .... but usually the opposition is re-assigned or fired. Some goes back to just after WW2, but there is also a lot about runup to Iraq invasion, including that justification for the invasion had started before 9/11
https://www.amazon.com/National-Insecurity-American-Militarism-ebook/dp/B00ATLNI04/
pg152/loc2138-42
It is not unusual for administrations to manipulate intelligence prior to embarking on war. This occurred before the Mexican-American War in order to support the policies of President James Polk, before the Spanish-American War in order to support the policies of President William McKinley, and in Lyndon B. Johnson's Vietnam War. The Bush administration was unique because of the institutionalization of the process. The president's chief of staff, Andrew Card, said it best, admitting that the White House had a "marketing plan," set to begin in September 2002 to justify the war.

... snip ...

This has a relative of Card interfacing to the Iraq UN delegation which before the invasion was offering to agree to any and all US terms; the person continued to point out before and after the invasion that the justification was fabricated ... resulting in persecution, prosecution, sent to military hospital and kept doped on drugs (reading it, I kept having to remind myself it wasn't fiction):
https://www.amazon.com/EXTREME-PREJUDICE-Terrifying-Patriot-ebook/dp/B004HYHBK2/

past posts mentioning Boyd &/or OODA-loop
https://www.garlic.com/~lynn/subboyd.html

--
virtualization experience starting Jan1968, online at home since Mar1970

Lisp machines, was What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp machines, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 02 Mar 2013 18:21:54 -0500
John Levine <johnl@iecc.com> writes:
You're probably thinking of Symbolics and LMI (Lisp Machines Inc), two competing spinoffs from MIT. The machine language wan't Lisp, but the architecture was designed to run Lisp efficiently, including stuff that was slow on conventional architecures like runtime type dispatching.

The Wikipedia articles are reasonably informative.


for the fun of it ... old email about MIT wanting 801/risc chip for lisp machine ... but Evans offering them 8100 instead:
https://www.garlic.com/~lynn/2003e.html#email790711
in this old post with various other 801/iliad refs
https://www.garlic.com/~lynn/2003e.html#65

also some discussion in this recent ibm-main mailing list post
https://www.garlic.com/~lynn/2013b.html#57

as per earlier references, ibm entry & mid-range mainframes were microcode and there was broad range of unique microprocessors that had been developed for each model requiring unique (micro)programming and (micro)programming tools. circa 79/80 there was an effort to converge the wide variety of internal microprocessors (used in controllers, devices, 370 processors, as well as microprocessor for original follow-on to s/38, as400) to 801/risc (mostly iliad chips) ... misc. old email mentioning 801/risc (including some iliad)
https://www.garlic.com/~lynn/lhwemail.html#801

for various reasons, all the efforts floundered ... and in the aftermath, saw some number of people leaving the company and going to work on risc efforts at other vendors.

the as/400 had a rush effort to come up with CISC chip (in place of 801/risc iliad) ... but later in the 90s did finally move to 801/risc (power/pc).

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 03 Mar 2013 11:25:26 -0500
Peter Flass <Peter_Flass@Yahoo.com> writes:
Lists three - correspondence (selectric), PTCC/BCD and PTTC/EBCDIC. There was also an APL character set.

pictures of selectric APL typeball here:
https://www.garlic.com/~lynn/lhwemail.html#oldpicts

2741 wiki
https://en.wikipedia.org/wiki/IBM_2741

from above:
The IBM 2741 came in two different varieties, some using "correspondence coding" and the others using "PTT/BCD coding." These referred to the positioning of the characters around the typeball and, therefore, the tilt/rotate codes that had to be applied to the mechanism to produce a given character. A "correspondence coding" machine could use type elements from a standard office Selectric (i.e. elements used for "office correspondence"). "PTT/BCD coding" machines needed special elements, and did not have as wide a variety of fonts available. The IBM 1050 and its derivatives were only available in PTT/BCD coding. The two element types were physically interchangeable, but code-incompatible, so a type element from, say, a System/360 console printer (a variety of IBM 1050) would produce gibberish on a "correspondence coding" 2741 or an office Selectric, and vice versa.

... snip ...

had translate tables that replaced byte contents with their tilt/rotate code (i.e. bit pattern sent to 2741 that controlled tilt/rotate of the typeball to position the desired charater for typing) ... and reverse translate table for converting incoming tilt/rotate code.

cp67 delivered to univ had "automatic" terminal identification to distinguish between whether it was talking to a 1052 or 2741 and set the corresponding line-scanner for that port.

GH20-0869-0 CP67 Version 3 Users Guide at bitsavers
http://bitsavers.trailing-edge.com/pdf/ibm/360/cp67/GH20-0859-0_CP67_Version_3_Users_Guide_Oct70.pdf
also at wayback machine
http://archive.org/details/bitsavers_ibm360cp67n3UsersGuideOct70_24706079

pg. 22 has images of pttc/ebcd 2741 keyboard and standard selectric keyboarad, pg. 28 describes
2. The system acknowledges that a communication line has been established by typing one of the following messages:

CP-67 ONLINE xxxxxxxxxxxx
xxxxxxxxxxxx CP-67 ONLINE

The first message is typed if the terminal is a 1052 or 2741 equipped with an EBCD character set. If the second message is typed, the 2141 bas a standard Selectric or correspondence character set. In either case, the xxxxxxxxxxxx portion of the message consists of meaningless characters and should be ignored.


... snip ...

the "xxxxx" is gibberish (system actually only types one message ... but it appears different depending on the type of 2741 you are using). Person then types "login" ... the input line is translated to ebcdic and checked for upper or lower case "l" ... if not it is checked for upper or lower case "y" ... if it is a "y", the line is untranslated (back to terminal input) and retranslated with the other translate table and rechecked for "l". the port control block is then set for the specific type of 2741 and corresponding translate table used.

the users manual also describes logging in with tty. As mentioned previously
https://www.garlic.com/~lynn/2013c.html#20 What Makes an Architecture Bizarre?

original cp67 delivered to univ, didn't have tty support, I did the implementation, which I sent back to the science center and they incorporated into the product.

this mentions cp67 crashing 27 times at the MIT Urban Systems lab.
http://www.multicians.org/thvv/360-67.html

science center was 4th flr 545 tech sq (bldg closest to the river), multics was on 5th flr, boston programming center on 3rd flr (but absorbed/taken over by the cp67 group when they split off from the science center). two other office bldgs formed the sq ... with a two-story bldg. for the 4th, street side (owned by poloroid for land, 4th flr offices overlooked land's balcony ... once we watched him demo'ing sr70 on the balcony before it had been announced). Bldgs have since all been remodeled & renumbered and looks totally different.

MIT Urban Systems Lab had cp67 in one of the other tech sq office bldgs across the square. I had done hack in the tty support with just one-byte in math calculations for line-length. Tom had hacked cp67 to increase tty max. line length to 1200 (I think a tty ascii plotter device done at harvard) which resulted in bad length calculations (resulting in the 27crashes in one day) because he hadn't changed the instructions with the one-byte use.

--
virtualization experience starting Jan1968, online at home since Mar1970

REFRPROT History Question

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: REFRPROT History Question
Newsgroups: bit.listserv.ibm-main
Date: 3 Mar 2013 08:57:53 -0800
PaulGBoulder@AIM.COM (Paul Gilmartin) writes:
That matches my old recollection of an Old Timer's recounting his astonishment at having read a dump in which a Protection Exception appeared to have been taken on a fetch instruction.

I believe (with no good evidence) that it was controlled by a bit in the page key. It may have been model-dependent. A matching PSW key always allowed read-write access; a different PSW key might have either no access or read-only access depending on the bit's setting.

Truly the Bad Old Days, when there was no privacy enforced between jobs. And IBM OS technology has always trailed the hardware technology. To wit, nowadays, the absence in z/OS of complete support for 64-bit virtual. (The less said of COBOL the better; it's not part of the OS.)

Jim Mulder's explanation is most plausible; at some point there may have been understandable reluctance to load user code in key 0, only partly because there would have been no way to guarantee confidentiality of such code.


cp67 had used games with storage protect key to provide integrity for cms shared pages (i.e. the same physical page appearing in multiple different virtual address spaces). It was a real ugly hack because cp67 had to fudge both the psw key that cms ran in as well as the storage keys (so no cms virtual machine could modify shared pages taking out other virtual machines).

in the move to vm370, part of the original 370 architecture was segment protection (bit in the segment table entry) and cms was reorganized so that it shared pages were in 4k page, 64kbyte segments (370 had 2kbyte & 4kbyte page options as well as 64kbyte and 1mbyte segment options).

however, 370/165 was starting to schedule slip with retofitting virtual memory hardware to the machine ... and in escalation meetings, it was decided to drop several features from 370 virtual memory ... including segment protect. As a result, all the other models that had already implemented full 370 virtual memory had to go back and remove the dropped features ... and any software written to use the dropped features had to be redone. This included the support for cms shared segments and returning to the ugly cp67 hack for protecting shared pages.

during the FS period (when company was shutting down 370 work), I continued to work on 370 ... moving a bunch of cp67 enhancements to vm370 base and doing lot more stuff like page-mapped filesystem (avoiding lots of the performance shortcomings of the tss/360 and paged mapped stuff being worked on for FS) as well as significantly extended shared segment capability. some old email
https://www.garlic.com/~lynn/2006v.html#email731212
https://www.garlic.com/~lynn/2006w.html#email750102
https://www.garlic.com/~lynn/2006w.html#email750430

with the death of FS, there was mad rush to get stuff back into the 370 product pipelines (the dearth of products during the FS period is also credited with giving the clone processor companies market foothold). some past posts
https://www.garlic.com/~lynn/submain.html#futuresys

This resulted in decision to release bits & pieces of stuff that i was distributing in csc/vm to internal datacenters (one of my hobbies was production systems for internal datacenters). A variation was some of the expanded shared segment stuff that I had done.

Somebody had come up with hack for vm370 version 3 that eliminated the storage key hack ... allowing VMA microcode assist to be used with CMS (LPSW VMA microcode didn't have the rules for the storage key hack). An executing cms virtual machine could now modify shared pages ... so to fence the effect ... on every task switch, all shared pages were scanned to see if they had been modified, if they had, they were unshared, and unmodified shared page was fetched from disk. The story was with single shared 16page segment, the overhead of scanning 16 pages for modification on every task switch was less than the performance gain from being able to use VMA with CMS.

The problem was that the inclusion of some of my shared segment enhancements ... also in version 3 ... increased the number of shared pages to be scanned on every task switch, invalidating the trade-off of better performance with VMA. I repeatedly pointed this out ... but eventually they came back and said that they couldn't drop the VMA use for CMS (reverything back to the cp67 storage key hack) ... because salesmen had pre-announced the VMA CMS use to 370/168 vm370 customers who had ordered VMA and paid substantial amount of money. The company couldn't go back and tell those customers that it had all been a mistake (and that the substantional amount they had paid for VMA was waste of money).

misc. past posts mentioning paged-map work
https://www.garlic.com/~lynn/submain.html#mmap

--
virtualization experience starting Jan1968, online at home since Mar1970

REFRPROT History Question

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: REFRPROT History Question
Newsgroups: bit.listserv.ibm-main
Date: 3 Mar 2013 12:05:55 -0800
re:
https://www.garlic.com/~lynn/2013c.html#31 REFRPROT History Question

Note this is part of old exchange of trying to get page protect for 3033 ... included in same hardware hits for MVSA microcode assist

old email partially posted previously here
https://www.garlic.com/~lynn/2006t.html#email800227

Date: 02/27/80 08:37:42
From: wheeler
To: numerous people in Endicott

re: yesterday's protect bit discussion. -- It does make a difference whether the proctect bit is in the page table entry or segment table entry (page table entry bit , I think may have originated MVS 811 hardware to provide them selective storage protection in addition to don't p*** on page zero for system protection). I was spending too much time thinking about the hardware implementation. Segment table entry protect bit provides selective protection for some users and the possibility of no protection for others, i.e. some virtual machines have R/W shared segments (DWSS) and others only have R/O access. Segment table protect bit is also defined in the original 370 architecture.

.. Lynn W., K03/281, San Jose Res., 408-256-1783 (8-276)

referenced note:

MY VERSION OF HARDWARE PAGE PROTECTION: WHEN UNDERTAKING AP DESIGN, SHARED PAGE PROBLEM WAS OBVIOUS. FIRST, I WAS TOLD BY POK MANAGEMENT (zzzzzzzz) THAT CMS MUST UTILIZE VMA MICROCODE. THIS WAS BECAUSE IBM WAS SELLING VMA TO 168 CUSTOMERS, AMONG OTHER REASONS. SO WE TRIED FOR PAGE PROTECTION. ARCHITECTURE SAID O.K. MVS SAID IT WOULD MAKE A NICE RAS TOOL, BUT THEY REALLY DID NOT CARE, AND DID NOT GET INVOLVED IN NEGOTIATIONS. WE DID NOT GET PAGE PROTECTION BECAUSE OF 168 MANUFACTURING. OUR EC WOULD HAVE HIT SEVERAL OF THE SAME CARDS AS MVSA (THEN IN THE WORKS). 168 PEOPLE INSISTED ON COMBINING PAGE PROTECT WITH MVSA TO REDUCE MANUFACTURING AND RECORD KEEPING COMPLEXITY. BUSINESS PEOPLE THEN SAID VM CUSTOMERS WOULD HAVE TO SHARE MVSA COSTS, SINCE IT WOULD BE PART OF PAGE PROTECT PACKAGE. AT THIS POINT VM BUSINESS CASE COLLAPSED AND WE GAVE UP THE FIGHT.

THE ONLY APPARENT ALTERNATIVE WAS TO ADOPT YOUR 'FACETIOUS' SUGGESTION TO DUPLICATE ALL SHARED SEGMENTS. WHAT SHOULD WE HAVE DONE??

.....

ABOUT CHANGES TO VMA SHARED PAGE SCAN, xxxxxxx, yyyyyyyy, AND I CERTAINLY ATTEMPTED TO OPTIMIZE BOTH SOFTWARE AND MICROCODE. THE MICROCODE DID NOT ALLOW FOR RELOCATABLE SHARED SEGMENTS SINCE WE DID NOT UNDERSTAND THE DESIRABILITY OF DOING SO. I SEE THIS AS PRIMARILY YOUR FAULT. SINCE YOU ENVISIONED THIS REQUIREMENT, YOU SHOULD HAVE EXPLAINED IT TO US. I CERTAINLY WOULD HAVE LISTENED.


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

"xxxxxx, yyyyyy, zzzzzzz" are to protect some of the guilty.

DWSS was internal support for the original relational database implementation, system/r
https://www.garlic.com/~lynn/submain.html#systemr

and getting DWSS included in vm370 product as shipping system/r as sql/ds (in period when favorite son operations were pre-occupied with getting out EAGLE as the new strategic database ... it wasn't until EAGLE crash&burn that attention was turned to possibly doing version of systemr/sqlds as DB2).
https://www.garlic.com/~lynn/submain.html#systemr

In a shared segment with same page table used by all virtual address spaces, a protection bit in the page table entry would apply to all address spaces. There was a unique segment table entry for every address space ... so with segment protect bit, it was possible to have some address spaces with the protect bit on and other address spaces with protect bit off.

Part of my full paged-mapped memory and shared segment support (small subset shipped in vm370 release 3) was any shared segment could occur at any virtual address in any virtual address space (even concurrently at different virtual addresses). The issue was limited to 16mbyte, 64kbyte shared segments was limited to 256 ... take out some system overhead and requirement for some shared systems being multiple shared segments ... possibly limited the number of unique shared systems around one hundred or so (across the whole system if unique system-wide virtual address was required for each shared application image). Relocating shared segments eliminated requirement for unique system-wide virtual address for each shared application. Then a specific CMS was limited to hundred or so concurrent shared applications (but in any combination ... rather than having the limitation system-wide). misc. pasts memory mapped posts
https://www.garlic.com/~lynn/submain.html#mmap

lots of old posts discussing problems that I had creating location free code (i.e. image on disk could be loaded at any virtual address w/o having to change it ... and the same image could occur simultaneously in multiple different address spaces at potentially different addresses)
https://www.garlic.com/~lynn/submain.html#adcon

this showed up because lots of CMS applications were done using os/360 compilers which generated relocatable address constants ... which had to be swizzled after loading .... fixing them to specific address. I basically had to undo all relocatable address constants in order to create location free code.

as an aside, lots of stuff I've done over the years, people have repeatedly claimed that it was my fault that they were unable to understand how great they were.

In the microcode assist arena, vm370 VMA would include virtual machine rules as option as part of machine instruction execution (avoiding several hundred instruction pathlength interrupt thru the vm370 kernel, reducing vm370 overhead from several hundred times to a couple percent). The other area of microcode assist was duplicating kernel pathlength instructions in microcode. This was done for the 138/148 ECPS ... discussed in this old post:
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

these were vertical microcode machines averaging 10 native instruction for every 370 instruction. ECPS did approx. one-for-one replacement getting ten times performance improvement. The problem was different with the high-end horizontal microcode machines, especially as things improved, 165 was approx. 2.1machine cycles per 370 instructions, 168 was 1.6machine cycles per 370, and 3033 it was down to approx. 1:1 ... nearly one machine cycle per 370 instruction. It was basically impossible to get any speedup doing ECPS-like microcode enhancements ... and because of certain side-effects, such microcode could even run slower than the 370 software implementation. I was told that was what happened with the MVS microcode on 3033 ... and people wanted all trace of their involvement erased ... since the features were supposedly justified as performance speedup ... and looking at benchmark numbers, it might be viewed that the requirement for new microcode in new MVS releases might have been done for other reasons.

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 03 Mar 2013 16:10:04 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
had translate tables that replaced byte contents with their tilt/rotate code (i.e. bit pattern sent to 2741 that controlled tilt/rotate of the typeball to position the desired charater for typing) ... and reverse translate table for converting incoming tilt/rotate code.

re:
https://www.garlic.com/~lynn/2013c.html#30 What Makes an Architecture Bizarre?

it was possible to send tilt/rotate code that "wiggled" the typeball but didn't actually type.

It was used with CMS "blip" command as sort of a reassurance that system hadn't forgotten you ... on long-running task ... it would indicate some progress was made with typeball wiggled after every couple seconds of cpu use.

its a little different from ftp hash comment which prints "#" after every 1kbytes transmitted ... since being able to count the hashes gives you amount of progress ... where typeball wiggle leaves no physical trace ... although it was possible to change blip default to actually print some character each time
https://en.wikipedia.org/wiki/CMS_EXEC

no longer supported:
http://publib.boulder.ibm.com/infocenter/zvm/v6r1/index.jsp?topic=/com.ibm.zvm.v610.dmsb4/hcsd8c01184.htm

--
virtualization experience starting Jan1968, online at home since Mar1970

The United States is leaking 1TB of data daily to foreign countries

From: lynn@garlic.com
Subject: The United States is leaking 1TB of data daily to foreign countries
Date: 4 Mar 2013
Blog: Information Security
The United States is leaking 1TB of data daily to foreign countries
http://www.dataconversionresource.com/9-track_magnetic_reel_tape_1600%20BPI_6250%20BPI.htm

Overall Malicious Activity, Top 10 Countries
https://www.team-cymru.org/

Amount of data tends to be related to how poor the security infrastructure is ... even if there might not be a direct relationship between amount of data and the value of the data.

For an example:

We were brought in to consult with a small client/server startup that wanted to do payment transactions on their server; they had also invented this technology called "SSL" that they wanted to use; the result is now frequently called "electronic commerce". As part of "electronic commerce" we had to do end-to-end look at various parts of "SSL", including operations that manufacture and issue the "SSL" digital certificates. We came up with some number of requirements for the deployment and operation ... some that were almost immediately violated, resulting in many of the vulnerabilities still seen to this day. some past posts related to ssl
https://www.garlic.com/~lynn/subpubkey.html#sslcerts

Possibly because of doing "electronic commerce", in the mid-90s, we were invited to participate in the x9a10 financial standard working group which had been given the requirement to preserve the integrity of the financial infrastructure for *ALL* retail payments. This involved doing end-to-end vulnerability and threat analysis of various payment operations (point-of-sale, attended, unattended, internet, etc). This resulted in the x9.59 financial transaction standard ... part of which eliminated leakage of payment transaction as vulnerability ... aka much of the breach news is about leakage of such information since crooks can use the information to perform fraudulent financial transactions (x9.59 eliminates the ability of the crooks to use that information for fraud). x9.59 reference
https://www.garlic.com/~lynn/x959.html#x959

Our characterization of the current paradigm (and the leakage of the information) has been

• In the current paradigm, the value of the information to the merchant (needing to protect the data) is the profit on the transaction (possibly a few dollars, possibly only a few cents for a transaction processor). The value of the information to the attacker is the account balance and/or credit limit (hundreds or thousands of dollars). As a result, crooks can afford to outspend by factor of 100 times attacking the system (as the merchants/processors can afford to spend defending).

• In the current paradigm, the information is required in dozens of business processes at millions of locations around the world ... which is dynamically opposed to the requirement to keep the information confidential and never divulged. As a result, we've commented that even if the planet was buried under miles of information hiding encryption, it still wouldn't prevent leakage.

As an aside, the greatest use of "SSL" in the world today is this earlier work we had done for "electronic commerce". However, in the x9.59 scenario it is no longer necessary to hide such information ... and therefor eliminates the major requirement for "SSL" in the world today (and the majority of the breaches that make the news today ... would no longer be news ... in fact, it eliminates a major motivation for performing many of the breaches).

past posts mentioning current paradigm:
https://www.garlic.com/~lynn/aadsm10.htm#cfppki14 CFP: PKI research workshop
https://www.garlic.com/~lynn/aadsm13.htm#12 Antwort: Re: Real-time Certificate Status Facility for OCSP - (RTCS)
https://www.garlic.com/~lynn/aadsm14.htm#1 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#4 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aadsm14.htm#33 An attack on paypal
https://www.garlic.com/~lynn/aadsm2.htm#keylength On leaving the 56-bit key length limitation
https://www.garlic.com/~lynn/aadsm2.htm#keyl2 On leaving the 56-bit key length limitation
https://www.garlic.com/~lynn/aadsm25.htm#38 How the Classical Scholars dropped security from the canon of Computer Science
https://www.garlic.com/~lynn/aadsm26.htm#18 SSL (https, really) accelerators for Linux/Apache?
https://www.garlic.com/~lynn/aadsm26.htm#25 EV - what was the reason, again?
https://www.garlic.com/~lynn/aadsm26.htm#58 Our security sucks. Why can't we change? What's wrong with us?
https://www.garlic.com/~lynn/aadsm27.htm#3 Solution to phishing -- an idea who's time has come?
https://www.garlic.com/~lynn/aadsm28.htm#3 Why Security Modelling doesn't work -- the OODA-loop of today's battle
https://www.garlic.com/~lynn/aadsm28.htm#5 Why Security Modelling doesn't work -- the OODA-loop of today's battle
https://www.garlic.com/~lynn/aadsm28.htm#19 Lack of fraud reporting paths considered harmful
https://www.garlic.com/~lynn/aadsm28.htm#60 Seeking expert on credit card fraud prevention - particularly CNP/online transactions
https://www.garlic.com/~lynn/aadsm28.htm#64 Seeking expert on credit card fraud prevention - particularly CNP/online transactions
https://www.garlic.com/~lynn/aadsm28.htm#71 Paypal -- Practical Approaches to Phishing -- open white paper
https://www.garlic.com/~lynn/aadsm28.htm#72 What are the current INNOVATIVE ICT Security Services, that are in demand or highly marketable at the moment
https://www.garlic.com/~lynn/aadsm28.htm#74 Visa and MasterCard mandated PCI compliance as of Jan 1, 2008. I would like to get a feel or opinion on this subject
https://www.garlic.com/~lynn/aadsm28.htm#75 Fun with Data Theft/Breach Numbers
https://www.garlic.com/~lynn/aepay11.htm#37 Who's afraid of Mallory Wolf?
https://www.garlic.com/~lynn/aepay3.htm#gaping gaping holes in security
https://www.garlic.com/~lynn/<h4>Message implementations
https://www.garlic.com/~lynn/aepay3.htm#gap2 [ISN] Card numbers, other details easily available at online stores
https://www.garlic.com/~lynn/2002c.html#7 Opinion on smartcard security requested
https://www.garlic.com/~lynn/2002j.html#14 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2002j.html#18 Symmetric-Key Credit Card Protocol on Web Site
https://www.garlic.com/~lynn/2006d.html#28 Caller ID "spoofing"
https://www.garlic.com/~lynn/2006e.html#44 Does the Data Protection Act of 2005 Make Sense
https://www.garlic.com/~lynn/2006k.html#4 Passwords for bank sites - change or not?
https://www.garlic.com/~lynn/2006k.html#5 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#17 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006k.html#18 Value of an old IBM PS/2 CL57 SX Laptop
https://www.garlic.com/~lynn/2006k.html#19 Hey! Keep Your Hands Out Of My Abstraction Layer!
https://www.garlic.com/~lynn/2006o.html#37 the personal data theft pandemic continues
https://www.garlic.com/~lynn/2006y.html#25 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007b.html#20 How many 36-bit Unix ports in the old days?
https://www.garlic.com/~lynn/2007b.html#33 security engineering versus information security
https://www.garlic.com/~lynn/2007b.html#60 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#43 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007c.html#53 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007d.html#34 Mixed Case Password on z/OS 1.7 and ACF 2 Version 8
https://www.garlic.com/~lynn/2007e.html#26 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007f.html#75 Securing financial transactions a high priority for 2007
https://www.garlic.com/~lynn/2007g.html#20 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007h.html#56 T.J. Maxx data theft worse than first reported
https://www.garlic.com/~lynn/2007i.html#64 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007i.html#65 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007j.html#15 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007k.html#76 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#39 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007l.html#48 My Dream PC -- Chip-Based
https://www.garlic.com/~lynn/2007o.html#28 EZPass: Yes, Big Brother IS Watching You!
https://www.garlic.com/~lynn/2007r.html#24 How to tell a fake SSL certificate from a real one
https://www.garlic.com/~lynn/2007s.html#16 The new urgency to fix online privacy
https://www.garlic.com/~lynn/2007u.html#67 folklore indeed
https://www.garlic.com/~lynn/2007v.html#70 folklore indeed
https://www.garlic.com/~lynn/2007v.html#74 folklore indeed
https://www.garlic.com/~lynn/2007v.html#86 folklore indeed
https://www.garlic.com/~lynn/2007v.html#87 Data Breaches Soar In 2007
https://www.garlic.com/~lynn/2007v.html#90 folklore indeed
https://www.garlic.com/~lynn/2007v.html#91 Tap and faucet and spellcheckers
https://www.garlic.com/~lynn/2007v.html#93 folklore indeed
https://www.garlic.com/~lynn/2007v.html#94 folklore indeed
https://www.garlic.com/~lynn/2007v.html#97 folklore indeed
https://www.garlic.com/~lynn/2008.html#2 folklore indeed
https://www.garlic.com/~lynn/2008.html#4 folklore indeed
https://www.garlic.com/~lynn/2008.html#9 folklore indeed
https://www.garlic.com/~lynn/2008c.html#47 Data Erasure Products
https://www.garlic.com/~lynn/2008e.html#66 independent appraisers
https://www.garlic.com/~lynn/2008h.html#20 handling the SPAM on this group
https://www.garlic.com/~lynn/2008i.html#21 Worst Security Threats?
https://www.garlic.com/~lynn/2008i.html#42 Security Breaches
https://www.garlic.com/~lynn/2008i.html#101 We're losing the battle
https://www.garlic.com/~lynn/2008m.html#56 With all the highly publicised data breeches and losses, are we all wasting our time?
https://www.garlic.com/~lynn/2008m.html#70 Why SSNs Are Not Appropriate for Authentication and when, where and why should you offer/use it?
https://www.garlic.com/~lynn/2008m.html#71 TJ Maxx - why are they still in business?
https://www.garlic.com/~lynn/2008m.html#72 What are security areas to be addressed before starting an e-commerce transaction or setting up a portal?
https://www.garlic.com/~lynn/2008n.html#54 In your experience which is a superior debit card scheme - PIN based debit or signature debit?
https://www.garlic.com/~lynn/2008n.html#75 Should online transactions be allowed on credit cards without adequate safeguards?
https://www.garlic.com/~lynn/2008n.html#90 Credit Card Security
https://www.garlic.com/~lynn/2008o.html#13 What risk of possible data leakage do you see for your organization?
https://www.garlic.com/~lynn/2008o.html#16 Is Information Security driven by compliance??
https://www.garlic.com/~lynn/2008o.html#22 What risk of possible data leakage do you see for your organization?
https://www.garlic.com/~lynn/2008o.html#76 Blinkenlights
https://www.garlic.com/~lynn/2008p.html#5 Privacy, Identity theft, account fraud
https://www.garlic.com/~lynn/2008p.html#7 Dealing with the neew MA ID protection law
https://www.garlic.com/~lynn/2008p.html#59 Can Smart Cards Reduce Payments Fraud and Identity Theft?
https://www.garlic.com/~lynn/2008r.html#53 21 million German bank account details on black market
https://www.garlic.com/~lynn/2008s.html#10 Data leakage - practical measures to improve Information Governance
https://www.garlic.com/~lynn/2009.html#60 The 25 Most Dangerous Programming Errors
https://www.garlic.com/~lynn/2009b.html#13 US credit card payment house breaches by sniffing malware
https://www.garlic.com/~lynn/2009b.html#62 Study: Data breaches continue to get more costly for businesses
https://www.garlic.com/~lynn/2009d.html#69 PCI Compliance
https://www.garlic.com/~lynn/2009f.html#36 PCI security rules may require reinforcements
https://www.garlic.com/~lynn/2009f.html#57 Data masking/data disguise Primer 1) WHY
https://www.garlic.com/~lynn/2009g.html#10 Top 10 Cybersecurity Threats for 2009, will they cause creation of highly-secure Corporate-wide Intranets?
https://www.garlic.com/~lynn/2009g.html#11 Top 10 Cybersecurity Threats for 2009, will they cause creation of highly-secure Corporate-wide Intranets?
https://www.garlic.com/~lynn/2009h.html#46 IBM security expert: X86 virtualization not ready for regulated, mission-critical apps
https://www.garlic.com/~lynn/2009i.html#14 Online Banking's Innate Security Flaws
https://www.garlic.com/~lynn/2009i.html#53 Merchant Groups Ask for Broad Changes in Letter to PCI's Overseer
https://www.garlic.com/~lynn/2009j.html#11 Is anyone aware of a system that offers three layers of security and ID protection for online purchases or even over the counter POS purchases?
https://www.garlic.com/~lynn/2009j.html#13 PCI SSC Seeks Input on Security Standards
https://www.garlic.com/~lynn/2009j.html#33 IBM touts encryption innovation
https://www.garlic.com/~lynn/2009j.html#41 How can we stop Credit card FRAUD?
https://www.garlic.com/~lynn/2009j.html#57 How can we stop Credit card FRAUD?
https://www.garlic.com/~lynn/2009k.html#54 The satate of software
https://www.garlic.com/~lynn/2009k.html#60 The satate of software
https://www.garlic.com/~lynn/2009l.html#53 Hacker charges also an indictment on PCI, expert says
https://www.garlic.com/~lynn/2009m.html#13 PCI Council Releases Recommendations For Preventing Card-Skimming Attacks
https://www.garlic.com/~lynn/2009m.html#22 PCI SSC Seeks standard for End to End Encryption?
https://www.garlic.com/~lynn/2009n.html#36 The Compliance Spectrum...Reducing PCI DSS Scope
https://www.garlic.com/~lynn/2009n.html#37 Firms failing to treat card data security seriously
https://www.garlic.com/~lynn/2009o.html#50 WSJ.com The Fallacy of Identity Theft
https://www.garlic.com/~lynn/2009r.html#29 Data Breaches Show PCI DSS Ineffective
https://www.garlic.com/~lynn/2009r.html#55 Verizon report goes deep inside data breach investigations
https://www.garlic.com/~lynn/2009s.html#39 Six Months Later, MasterCard Softens a Controversial PCI Rule
https://www.garlic.com/~lynn/2009s.html#44 PCI and Network Encryption
https://www.garlic.com/~lynn/2010f.html#29 Cyberattacks raise e-banking security fears
https://www.garlic.com/~lynn/2010f.html#75 Is Security a Curse for the Cloud Computing Industry?
https://www.garlic.com/~lynn/2010g.html#84 In SSL We Trust? Not Lately
https://www.garlic.com/~lynn/2010i.html#25 Retailers blamed for making people vulnerable to credit card fraud and ID theft
https://www.garlic.com/~lynn/2010i.html#58 Cyber Self Defense: Reduce Your Attack Surface
https://www.garlic.com/~lynn/2010k.html#5 The Attacker's Advantage
https://www.garlic.com/~lynn/2010l.html#70 A slight modification of my comments on PKI
https://www.garlic.com/~lynn/2010l.html#79 Five Theses on Security Protocols
https://www.garlic.com/~lynn/2010m.html#29 Are we spending too little on security? Or are we spending too much??
https://www.garlic.com/~lynn/2010m.html#64 How Safe Are Online Financial Transactions?
https://www.garlic.com/~lynn/2010n.html#46 Who are these people who think cybersecurity experts are crying wolf?
https://www.garlic.com/~lynn/2010n.html#49 ZeuS attacks mobiles in bnak SMS bypass scam
https://www.garlic.com/~lynn/2010o.html#8 PCI: Smaller Merchants Threatened
https://www.garlic.com/~lynn/2010o.html#28 Survey Outlines Compliance Challenge Among Small Merchants
https://www.garlic.com/~lynn/2010o.html#31 Survey Outlines Compliance Challenge Among Small Merchants
https://www.garlic.com/~lynn/2010o.html#53 The Credit Card Criminals Are Getting Crafty
https://www.garlic.com/~lynn/2010o.html#76 E-commerce smackdown as PCI standards revised
https://www.garlic.com/~lynn/2010q.html#4 Plug Your Data Leaks from the inside
https://www.garlic.com/~lynn/2011b.html#36 Internal Fraud and Dollar Losses
https://www.garlic.com/~lynn/2011h.html#58 Pipeline and Network Security: Protecting a Series of Tubes
https://www.garlic.com/~lynn/2011j.html#63 Why do defenders keep losing to smaller cyberwarriors?
https://www.garlic.com/~lynn/2011l.html#47 Does outsourcing cause data loss?
https://www.garlic.com/~lynn/2011n.html#15 Wicked Problems
https://www.garlic.com/~lynn/2011n.html#47 PCI and the Insider Threat
https://www.garlic.com/~lynn/2011o.html#1 Silicoin
https://www.garlic.com/~lynn/2011o.html#13 Two-Factor Authentication - Hardware token or SMS OTP
https://www.garlic.com/~lynn/2012b.html#94 public key, encryption and trust
https://www.garlic.com/~lynn/2012c.html#11 The 15 Worst Data Security Breaches of the 21st Century
https://www.garlic.com/~lynn/2012d.html#49 Do you know where all your sensitive data is located?
https://www.garlic.com/~lynn/2012d.html#68 Memory versus processor speed
https://www.garlic.com/~lynn/2012e.html#17 Data theft: Hacktivists 'steal more than criminals'
https://www.garlic.com/~lynn/2012i.html#31 US Senate proposes national data breach notification act
https://www.garlic.com/~lynn/2012i.html#35 US Senate proposes national data breach notification act
https://www.garlic.com/~lynn/2012j.html#47 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
https://www.garlic.com/~lynn/2012j.html#56 Failing Gracefully
https://www.garlic.com/~lynn/2012j.html#64 The Myth of Password Complexity & Frequent Change Rules
https://www.garlic.com/~lynn/2012j.html#72 Bank Sues Customer Over ACH/Wire Fraud
https://www.garlic.com/~lynn/2012l.html#52 I.B.M. Mainframe Evolves to Serve the Digital World
https://www.garlic.com/~lynn/2012m.html#10 Does the IBM System z Mainframe rely on Security by Obscurity or is it Secure by Design
https://www.garlic.com/~lynn/2012n.html#58 2012 History Conference
https://www.garlic.com/~lynn/2012n.html#63 history of Programming language and CPU in relation to each other
https://www.garlic.com/~lynn/2012o.html#23 Does the IBM System z Mainframe rely on Security by Obscurity or is it Secure by Design?

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 04 Mar 2013 11:06:49 -0500
Peter Flass <Peter_Flass@Yahoo.com> writes:
I was mostly using IPCS, but I ran into one storage overlay problem where it was easier to print out a box of paper and eyeball it. The overlay was obvious at a glance (lots of memory clobbered by some text data).

upthread reference to having redone IPCS:
https://www.garlic.com/~lynn/2013c.html#25 What Makes an Architecture Bizarre?
other recent references to having redone IPCS:
https://www.garlic.com/~lynn/2013.html#29 Java Security?
https://www.garlic.com/~lynn/2013b.html#60 New HD

It was in early days of REX (before rename to REXX and released to customers) and I wanted to show it wasn't just another pretty scripting language. At the time, IPCS was quite large, assembler implementation ... my objective was to do REX implementation that had ten times more function, ran ten times faster ... and do it half-time in 3months elapsed (the part about making interpreted REX run ten times faster than the assembler was good hack). I finished early, so started developing library of routines that would automatically examine dump for large variety of known failure signatures.

I had assumed that it would be released to customers and for whatever reason, it wasn't ... even though it came to be used by most of the internal datacenters and customer support PSRs. I finally did get approval for doing presentations at user group meetings on how I did the implementation ... and within a few months ... other implementations started appearing.

misc. past posts mentioning dumprx
https://www.garlic.com/~lynn/submain.html#dumprx

--
virtualization experience starting Jan1968, online at home since Mar1970

Lisp machines, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp machines, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 04 Mar 2013 11:22:25 -0500
Quadibloc <jsavard@ecn.ab.ca> writes:
I'm surprised nobody''s mentioned APL yet. Custom microcode for an experimental 360/30, the portable MCM computer, and a few other attempts, I think.

there was 370/145 microcode assist for APL ... but it wasn't the language ... it was microcode implementation that made parts of the APL interpreter run (ten times) faster (aka with the assist, 145 ran APL nearly as fast as 168). done at palo alto science center ... same people that brought you the luggable
https://en.wikipedia.org/wiki/IBM_5100

I got sucked into working by Endicott on the VM ECPS microcode for 138/148 ... and made runs with heavily instrumented vm370 kernel that generated log with timestamped entries at numerous execution points in the kernel:
https://www.garlic.com/~lynn/94.html#21 370 ECPS VM micrcode assist

138/148 had 6kbytes available for moving 370 code into microcode on approx. one-for-one basis ... the above shows results sorted by frequency of use and cutoff at 6kbytes of highest used kernel code (approx. 80% of total time spent in the kernel).

however, the person that had done the 370/145 APL microcode generated special hotspot monitor ... microcode table of entry counts for ranges of address (word counter for every 64bytes in the kernel) ... it would periodically wake up and increment the counter corresponding to the 370 instruction address. this was also used as part of validating the other analysis.

the boston programming center did cps ... interactive basis and PLI and had microcode for the 360/50 (analogous to what was done for apl on 370/145).
http://www.bitsavers.org/pdf/allen-babcock/cps/CPS_Progress_Report_may66.pdf

misc. past posts mentioning CPS & Allen-Babcock:
https://www.garlic.com/~lynn/2008s.html#71 Is SUN going to become x86'ed ??
https://www.garlic.com/~lynn/2010e.html#14 Senior Java Developer vs. MVS Systems Programmer (warning: Conley rant)
https://www.garlic.com/~lynn/2012e.html#100 Indirect Bit
https://www.garlic.com/~lynn/2012n.html#26 Is there a correspondence between 64-bit IBM mainframes and PoOps editions levels?
https://www.garlic.com/~lynn/2013c.html#8 OT: CPL on LCM systems [was Re: COBOL will outlive us all]

--
virtualization experience starting Jan1968, online at home since Mar1970

PDP-10 byte instructions, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: PDP-10 byte instructions, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 04 Mar 2013 13:30:30 -0500
John Levine <johnl@iecc.com> writes:
Dunno about how it'd affect what you'd put on a tape, but it would have made the implementation considerably messier if a single byte instruction could read and write two words, since those two words could have been in different pages. There were instructions that did a doubleword load or doubleword store, but I don't recall any that did a doubleword read-modify-write, much less one that only sometimes did it. The byte instructions already had special status bit "first part done" for a restart hack since for the instructions that incremented a byte pointer and then read or wrote the byte, an interrupt could happen between the increment and the byte access.

when charlie was working on fine-grain multiprocessor locking for cp67, at the science center, he invented the compare&swap instruction. the initial attempt at getting it justified for 370 was rebuffed, the claim by the favorite son operating system people in POK was that the test&set instruction from 360 was more than sufficient. the owners of the architecture/redbook said that to justify the instruction would require non-multiprocessor scenarios ... thus was born the example uses (still appear in principles of operation) for multithreaded applications ... used for atomic conditional replace ... where an interrupt might occur between the read & write (regardless of running in single processor or multi-processor environment) Both a single word & double word compare&swap was added to 370. instruction name compare-and-swap was chosen because CAS are charlie's initials. misc. past posts mentioning science center
https://www.garlic.com/~lynn/subtopic.html#545tech

by the mid-80s it was in use for large DBMS multi-threaded systems and instruction with similar semantics appearing in other architectures.

one of the problems for rs/6000 competition with other vendors in the DBMS market was the lack of instruction with compare&swap semantics ... forcing it to fall back to high overhead kernel calls for locking & correct serialization. Eventually aix provided compare&swap simulation with fastpath code occurring in the kernel call interrupt handler (with immediate return) to mitigate the performance penalty with other platforms. This worked because rs/6000 was single-processor only ... and in the kernel call interrupt handler, it was disabled for interrupts.

misc. past posts mentioning compare&swap and/or multiprocessor
https://www.garlic.com/~lynn/subtopic.html#smp

misc. past posts mentioning original relational/sql implementation
https://www.garlic.com/~lynn/submain.html#systemr

in this sql reunion
http://www.mcjones.org/System_R/

there was (incorrect) conjecture that compare&swap was from senior person in POK (not charlie)
http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-Shoot-ou.html

from above:
I don't have the exact date, but around 1978, right? When did the actual shoot-out occur? 1978? Gomory asked Dick Case to do a review of the work. Dick Case included Ashok Chandra, who currently runs the Computer Science Department - he's the latest version of Frank King - and one other person, who were all disinterested people, but were technically capable. They went to Yorktown and learned all about QBE, and then they came to San Jose to learn all about System R, and I gave them my long lecture about how the lock manager works and how Compare-and-Swap could do locking, and we did it all right, and we knew how to do Compare-and-Swap-Double. Dick Case was really impressed, because he's probably the architect of Compare-and-Swap.

... snip ...

who happened earlier to have been (also) heavily involved in FS
https://www.garlic.com/~lynn/submain.html#futuresys

recent post reference DWSS which was also used for System/R and tried to get it included in standard product as part of morph of System/R into SQL/DS product.
https://www.garlic.com/~lynn/2013c.html#31 REFRPROT History Question
https://www.garlic.com/~lynn/2013c.html#33 REFRPROT History Question

--
virtualization experience starting Jan1968, online at home since Mar1970

Russia to buy no more foreign drones

Refed: **, - **, - **
From: lynn@garlic.com
Subject: Russia to buy no more foreign drones
Date: 4 Mar 2013
Blog: Facebook
Russia to buy no more foreign drones
http://www.globalsecurity.org/intell/library/news/2013/intell-130302-vor01.htm

from above:
When commenting on the borrowing of foreign technologies, the official pointed out that the USSR was the first to invent a drone, based on the Tu-154 airliner, back in the 1960s.

... snip ...

possibly a little later, NKP gone 404, but lives on at wayback machine
https://web.archive.org/web/20030212092342/http://home.att.net/~c.jeppeson/igloo_white.html

from above:
Batcat flights were replaced by a joint USAF/DARPA program code-named Pave Eagle that was phased in for operational field trials in 1970. Under the program, six Beech A-36 Debonaire airframes were modified as YQU-22A development aircraft. Later, one was designated as YAU-22A, and twenty seven were produced as QU-22B aircraft, intended to be operated as pilotless drones. A Detachment of 554th Reconnaissance Wing, Udorn flew the airborne signals reception missions out of both Udorn and Nakhon Phanom RTAFB . Between 1970 and 1972, six aircraft were lost through mechanical failure, and one from pilot hypoxia. Records indicate that when the program closed, QU-22 'Quackers' never flew operationally as pilotless drones as initially programmed. Reliable eyewitness accounts indicate that they were seen flying pilotless on occasion, but other information indicates that the Commander at NKP issued a standing order that none were to be flown operationally without a pilot.

... snip ...

Does anyboy know if this might have been John??

posts mentioning Boyd &/or OODA-loops:
https://www.garlic.com/~lynn/subboyd.html

recent posts specifically referencing spook base:
https://www.garlic.com/~lynn/2012f.html#41 Hi, Does any one knows the true origin of the usage of the word bug in computers to design a fault?
https://www.garlic.com/~lynn/2012h.html#24 Baby Boomer Guys -- Do you look old? Part II
https://www.garlic.com/~lynn/2012h.html#63 Is this Boyd's fundamental postulate, 'to improve our capacity for independent action'?
https://www.garlic.com/~lynn/2012i.html#8 Interesting News Article
https://www.garlic.com/~lynn/2012i.html#44 Simulated PDP-11 Blinkenlight front panel for SimH
https://www.garlic.com/~lynn/2012i.html#51 Is this Boyd's fundamental postulate, 'to improve our capacity for independent action'? thoughts please
https://www.garlic.com/~lynn/2012i.html#61 a clock in it, was Re: Interesting News Article
https://www.garlic.com/~lynn/2012i.html#64 Early use of the word "computer"
https://www.garlic.com/~lynn/2012j.html#43 A lesson from history about wasted valor, for which a price might be asked of us
https://www.garlic.com/~lynn/2012j.html#75 Excellent and recommended
https://www.garlic.com/~lynn/2012l.html#45 Introducing John Boyd
https://www.garlic.com/~lynn/2012n.html#60 The IBM mainframe has been the backbone of most of the world's largest IT organizations for more than 48 years
https://www.garlic.com/~lynn/2012p.html#59 How do we fight bureaucracy and bureaucrats in IBM?

--
virtualization experience starting Jan1968, online at home since Mar1970

NPC Luncheon with Thomas Drake, NSA Whistleblower

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: NPC Luncheon with Thomas Drake, NSA Whistleblower
Date: 4 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
NPC Luncheon with Thomas Drake, NSA Whistleblower
http://www.press.org/events/npc-luncheon-thomas-drake-nsa-whistleblower

series in local paper ... summary here (Success of Failure culture)
http://www.govexec.com/excellence/management-matters/2007/04/the-success-of-failure/24107/

reference that the Success of Failure culture was spreading through gov. agencies and beltway bandits.

wiki page:
https://en.wikipedia.org/wiki/Thomas_Andrews_Drake

x-over from another discussion here ... conjecture that beltway bandits used game theory to maximize revenue ... realizing a series of failed efforts is more revenue than an immediate success ... aka another unintended consequence

"Game theory, or using math to find the optimal solution to complex systems"
http://blogs.scientificamerican.com/guest-blog/2013/02/27/why-its-smart-to-be-reckless-on-wall-street/

recent thread also mentioning game theory article
https://www.garlic.com/~lynn/2013c.html#16 A Matter of Mindset: Iraq, Sequestration and the U.S. Army
https://www.garlic.com/~lynn/2013c.html#28 A Matter of Mindset: Iraq, Sequestration and the U.S. Army

recent posts mentioning whistleblower:
https://www.garlic.com/~lynn/2013.html#41 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#16 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#27 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#36 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#47 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#64 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013c.html#6 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#18 WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
https://www.garlic.com/~lynn/2013c.html#19 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#26 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

30 years of PCWorld, 30 pivotal moments in PC history

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 30 years of PCWorld, 30 pivotal moments in PC history
Newsgroups: alt.folklore.computers
Date: Mon, 04 Mar 2013 16:55:52 -0500
30 years of PCWorld, 30 pivotal moments in PC history
http://www.pcworld.com/article/2027069/30-years-of-pcworld-30-pivotal-moments-in-pc-history.html
30 years of PCWorld, 30 pivotal moments in PC history
http://www.networkworld.com/news/2013/041613-pirate-bay-co-founder-charged-with-268766.html

--
virtualization experience starting Jan1968, online at home since Mar1970

Danger as stock-market "Greedometer" flashes red

From: lynn@garlic.com
Subject: Danger as stock-market "Greedometer" flashes red
Date: 4 Mar 2013
Blog: Google+
re:
https://plus.google.com/u/0/102794881687002297268/posts/T5bT9qCbFBT

Danger as stock-market "Greedometer" flashes red
http://www.marketwatch.com/story/danger-as-stock-market-greedometer-flashes-red-2013-02-28

VIX 'Sell-And-Roll' Volume Explodes, Replacing Equity 'Buy-And-Hold' In The New Normal
http://www.zerohedge.com/news/2013-03-04/vix-sell-and-roll-volume-explodes-replacing-equity-buy-and-hold-new-normal

Shorting The Market On These March Days Will Be Hazardous To Your Health
http://www.zerohedge.com/news/2013-03-04/shorting-market-these-march-days-will-be-hazardous-your-health

Fed can fix the economy
http://www.atimes.com/atimes/Global_Economy/GECON-01-270213.html

from above:
Quantitative easing (QE) is supposed to stimulate the economy by adding money to the money supply, increasing demand. But so far, it hasn't been working. Why not? Because as practiced for the last two decades, QE does not actually increase the circulating money supply. It merely cleans up the toxic balance sheets of banks. A real "helicopter drop" that puts money into the pockets of consumers and businesses has not yet been tried. Why not?

When Ben Bernanke gave his famous helicopter money speech to the Japanese in 2002, he was not yet chairman of the Federal Reserve. He said then that the government could easily reverse a deflation, just by printing money and dropping it from helicopters.


... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 4 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
In case you missed it, Occupy Wall Street just sued every federal regulator on Wall Street
http://johnhively.wordpress.com/2013/03/04/occupy-wall-street-is-alive-and-well-and-suing-all-federal-regulators/

Occupy the SEC, Frustrated With Regulatory Defiance of Volcker Rule Implementation Requirements, Sues Fed, SEC, CFTC, FDIC and Treasury
http://www.nakedcapitalism.com/2013/02/occupy-the-sec-frustrated-with-regulatory-defiance-of-volcker-rule-implementation-requirements-sues-fed-sec-cftc-fdic-and-treasury.html

past posts in this thread:
https://www.garlic.com/~lynn/2013.html#44 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#51 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#57 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#66 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#48 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#65 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#74 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#5 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#26 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
Date: 4 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
Foreclosure Files Detail Error Gap
http://online.wsj.com/article/SB10001424127887323293704578332560551745742.html

from above:
Some of the country's biggest banks were on pace to find a higher rate of past foreclosure mistakes than regulators disclosed in January when they halted a review in favor of a $9.3 billion settlement for homeowners.

... snip ...

Servicers Committed Loan Error Rates of Either 4.2% or 97.2%, Take Your Pick
http://www.nakedcapitalism.com/2013/03/dave-dayen-servicers-committed-loan-error-rates-of-either-4-2-or-97-2-take-your-pick.html

from above:
So depending on who you believe, either OCC or the HUD IG, servicers either generated error rates of 4.2% or 97.2%.

... snip ...

Congressmen Criticizing OCC Mortgage Settlement, While More Misrepresentations and Coverups Emerge
http://www.nakedcapitalism.com/2013/03/congressmen-criticizing-occ-mortgage-settlement-while-moremisrepresentations-and-coverups-emerges.html

from above:
Last week, the Wall Street Journal publicized that the OCC cooked the books in its incredible claim that only 4.2% of the files examined in the recently shuttered foreclosure reviews showed harm. It looked like a case of lying with statistics, in that the Journal noticed that they had cited a higher error rate at the time of the settlement (6.5%), and then added a bunch of JP Morgan completed reviews to the sample. And why was that helpful? It looks like JP Morgan didn't finish its review of all those drecky Bear Stearns loans, so only the prettier JP Morgan-originated ones got counted. How convenient.

... snip ...

Reports: Four Banks Seized Over 700 Military Homes
http://www.military.com/daily-news/2013/03/04/reports-four-banks-seized-over-700-military-homes.html

from above:
The New York Times reported Monday that Bank of America, Wells Fargo, JPMorgan Chase, and Citigroup uncovered hundress of cases of wrongful foreclosures of military personnel that occurred between 2009 and 2010.

... snip ...

Fallout from 'Untouchables' Documentary: Another Wall Street Whistleblower Gets Reamed
http://www.rollingstone.com/politics/blogs/taibblog/fallout-from-untouchables-documentary-another-wall-street-whistleblower-gets-reamed-20130304

--
virtualization experience starting Jan1968, online at home since Mar1970

Lisp machines, was What Makes an Architecture Bizarre?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp machines, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 04 Mar 2013 21:20:43 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
there was 370/145 microcode assist for APL ... but it wasn't the language ... it was microcode implementation that made parts of the APL interpreter run (ten times) faster (aka with the assist, 145 ran APL nearly as fast as 168). done at palo alto science center ... same people that brought you the luggable
https://en.wikipedia.org/wiki/IBM_5100


How an 83-Year-Old Inventor Beat the High Cost of 3D Printing
http://techland.time.com/2013/03/04/how-an-83-year-old-inventor-beat-the-high-cost-of-3d-printing/

from above:
That inventor is 83-year-old Hugh Lyman, who lives near Enumclaw, Wash., 35 miles southeast of Seattle. Until he retired 17 years ago, Lyman ran Ly Line Products, a manufacturer of scientific cabinetry and related items such as fume hoods. He's been a forward-thinking technologist for a long time: in 1976, Computerworld magazine wrote about Ly Line's use of the IBM 5100, an early "portable computer" which weighed 55 pounds.

... snip ...

computerworld 30aug1976
http://books.google.com/books?id=AIYfudRBgagC&lpg=RA1-PA36&ots=AsJxJxrjm7&dq=ibm%205100%20hugh%20lyman&pg=RA1-PA36#v=onepage&q=ibm%205100%20hugh%20lyman&f=false

--
virtualization experience starting Jan1968, online at home since Mar1970

A Matter of Mindset: Iraq, Sequestration and the U.S. Army

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: A Matter of Mindset: Iraq, Sequestration and the U.S. Army
Date: 5 Mar 2013
Blog: Facebook
re:
https://www.garlic.com/~lynn/2013c.html#16 A Matter of Mindset: Iraq, Sequestration and the U.S. Army
https://www.garlic.com/~lynn/2013c.html#28 A Matter of Mindset: Iraq, Sequestration and the U.S. Army

National Insecurity (author 20yrs at CIA) pg269/loc3849-54:
Obama's appointment of General Petraeus completed the militarization of the intelligence community with only the State Department's INR outside the orbit of the Pentagon's influence. The general is accustomed to a chain-of-command, top-down process at the Pentagon and would have been shocked by the original contrarian nature of the intelligence culture as well as the bottom-up culture of the CIA. He is used to "Sirs" and salutes, which were once antithetical to the intelligence culture. The military culture considers contrarians, the source of many intelligence successes, to be dissenters. Conventional wisdom reigns at the Pentagon, where contrarians are pushed aside.

... snip ...

In Organic Design briefings, Boyd would reference DOD being rigid, top-down, command&control structure (implication that only those at the very top knew what they were doing and everybody else requiring moment-to-moment direction) ... antithetical to many areas requiring high level of skill & expertise.

In (closed linkedin) Financial Crime Risk, Fraud and Security there are a number of long running discussions related to whistle-blowers ... just posted is reference to person behind the Success of Failure culture referenced upthread
http://www.press.org/events/npc-luncheon-thomas-drake-nsa-whistleblower
also person's wiki page:
https://en.wikipedia.org/wiki/Thomas_Andrews_Drake

a little more from Spinney; Chuck Spinney: Buy Before You Fly ... How to Suck Money During Sequestration [...Legalized Treason?]
http://www.phibetaiota.net/2013/03/chuck-spinney-buy-before-you-fly-or-how-to-suck-money-during-the-politics-of-austerity-or-legalized-treason-holding-the-public-in-total-contempt/

National Insecurity pg351/loc5037-42:
In a congressional briefing in May 2011, it was learned that less than 2 percent of the cost of each F-35 pays for labor costs in "manufacturing, fabrication, and assembly" work at the plane's main production facility in Fort Worth, Texas. 40 Conversely, more than 85 percent of the F-35 costs go for overhead, which has nothing to do with jobs that fabricate and assemble the aircraft.

... snip ...

When Money is No Object: the Strange Saga of the F-35
http://www.counterpunch.org/2013/03/04/when-money-is-no-object-the-strange-saga-of-the-f-35/

Boyd &/or OODA-loop related posts
https://www.garlic.com/~lynn/subboyd.html

recent "Fincial Crime Risk, Fraud and Security" whistle-blower related posts:
https://www.garlic.com/~lynn/2013.html#41 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#16 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#27 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#36 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#47 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#64 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013c.html#6 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#18 WhistleWatch -- Blog Archive -- Former Top Federal Whistleblower Protector Scott Bloch, Esq. Pleads Guilty to Destruction of Government Property
https://www.garlic.com/~lynn/2013c.html#19 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#26 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#39 NPC Luncheon with Thomas Drake, NSA Whistleblower
https://www.garlic.com/~lynn/2013c.html#43 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Tue, 05 Mar 2013 16:54:37 -0500
hancock4 writes:
While they never achieved a unified product line (and still don't), they came a lot closer than the situation in the early 1960s. Back then, IIRC, they had to support at least the 650, 7090, 14xx, 705, and 1620 architectures, all of which were completely different.

Later they had the System/3, 1130, and S/360; and the 1130 shared some aspects with S/360. S/3 did require a complete break in order to get the price down low--it had a much smaller instruction set and simpler hardware. The 1130 was also a budget oriented machine

I think in the 1960s, the System/360 addressing scheme was adequate for even high end machines, I doubt _back then_ a unit went beyond 16 meg memory. I think IBM's problem in large scientific systems was IBM's CPU's just weren't as fast as competition such as Cray and CDC, who were more specialized in high end work. Also, IBM probably wasn't cost-competitive.

Somewhere I read that the ratio of business vs. sci/eng problems on S/ 360 was 70-30. I can't help but suspect there were plenty of well satisfied sci/eng users banging away in Fortran on their S/360 et al (or using a product like SPSS). Indeed, I knew some econmetric forecasters making good use of high-end S/360-370 for complicated modeling.


recent ibm-main mailing list post mentioning acs-360
https://www.garlic.com/~lynn/2013b.html#73 One reason for monocase

End of IBM ACS Project
https://people.computing.clemson.edu/~mark/acs_end.html

from above:
Of the 26,000 IBM computer systems in use, 16,000 were S/360 models (that is, over 60%). [Fig. 1.311.2]

Of the general-purpose systems having the largest fraction of total installed value, the IBM S/360 Model 30 was ranked first with 12% (rising to 17% in 1969). The S/360 Model 40 was ranked second with 11% (rising to almost 15% in 1970). [Figs. 2.10.4 and 2.10.5]

Of the number of operations per second in use, the IBM S/360 Model 65 ranked first with 23%. The Univac 1108 ranked second with slightly over 14%, and the CDC 6600 ranked third with 10%. [Figs. 2.10.6 and 2.10.7]


... snip, and:
To achieve a profit for the ACS program, Amdahl asked IBM management to approve three ACS-360 models: the high-performance design, a 1/3 performance version, and a 1/9 performance version. He felt that these performance goals would be a good fit with the System 360 marketing plans. He remembers that IBM Corporate Marketing evaluated the targets and reported: 1) the supercomputer alone was a loss leader! 2) the supercomputer plus the 1/3 performance computer was break-even! And 3) the supercomputer plus both the 1/3 performance computer and the 1/9 performance computer was normal profit -- 30% pre-tax! He remembers meeting with "the Divisional President and Vice President who worked on me for over an hour to get me to modify the multipliers of my 3 computers (which would increase their cost without increasing their market acceptance nearly as much)."

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Tue, 05 Mar 2013 17:01:02 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
recent ibm-main mailing list post mentioning acs-360
https://www.garlic.com/~lynn/2013b.html#73 One reason for monocase

End of IBM ACS Project
https://people.computing.clemson.edu/~mark/acs_end.html


re:
https://www.garlic.com/~lynn/2013c.html#46 What Makes an Architecture Bizarre?

also from "End of IBM ACS Project" (excerpt from Gene Amdahl interview):
The first thing I did was have the two smaller computers costed. I then submitted the three system plan to corporate pricing. The single highest speed computer was a loss leader. The second smaller computer added made a break-even program. Adding the third even smaller computer came out with normal profit! IBM management decided not to do it, for it would advance the computing capability too fast for the company to control the growth of the computer marketplace, thus reducing their profit potential. I then recommended that the ACS lab be closed, and it was.

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 06 Mar 2013 11:48:11 -0500
Robert Wessel <robertwessel2@yahoo.com> writes:
Even assuming those things had been messed up in the original implementation, fixing them was possible (as the did in 32-bit mode on the 360/67).

But the OS guys punted a huge amount of 24 bit stuff into application visible storage (mainly to save space in the kernel**), and simple fixes were no longer possible. Certain things applications do *still* have to be in 24 bit space in zOS.

*A trivial rearrangement of the CCW is exactly what they did for 31-bit support in XA.

**A classic example of how insufficiently thought out and specified priorities can lead to horrible things - in the case of OS/360, it was "the OS must fit in X bytes". That was a reasonable goal, given the extreme cost of memory (if no customers can't afford enough memory to run the OS, it doesn't bode well for the project), but it was not understood sufficiently (or perhaps it was ignored) how bad making all that stuff user-mode visible was. So the guys doing the file-I/O stuff made their memory targets***, but to this day zOS simulates old processing so that it can keep the file control blocks exposed (and documented!) in user storage looking and acting (yes, some of the fields are writable by the application) like they did 50 years ago.

***The OS/360 guys blew their memory targets pretty badly anyway (OS/360 never really could run on the small machines), and that doubtless led to some of the desperation to save space.


IDALs were introduced for 370 ... which allowed for full word addresses. CCWs were 8bytes, 1byte opcode, followed by 24bit address plus another word of stuff. Operation of channel were spec'ed that there was no prefetching ... the previous CCW had to complete before the next CCW could be fetched. This periodically resulted in timing & overrun problems

It also created a big problem moving from real to virtual. CP67 virtual machine support had to create shadow channel program ... where real addresses were substituted in CCWs for the virtual addresses from the virtual machine cahnnel program. The other issue was that a single virtual CCWs could specify contiguous area that crossed page boundary ... that weren't contiguous in the real machine. In order to simulate this, required replacing a single CCW with pair of CCWs for each non-contiguous page crossing .... using "data-chaining" from the starting CCW to following CCW with non-contiguous address (i.e. a data-chained CCW inherits the op-code from the previous CCW but allows to specify new address), however a data-chained CCW is still restricted to no-prefetching restriction ... aka the previous CCW has to have completely completed ... before the fetch of the data-chained to CCW. Since the device is still transferring data, the latency for fetching the following CCW can expose timing overrun.

Introduced for 370 was "IDALs" ... the CCW has the IDAL flag set, and the 24bit bit address doesn't point to the data area ... but a table of contiguous fullword addresses (specifying the data areas). IDAL table can be used for the same purpose as data-chaining (specifying non-contiguous data areas ... aka scatter/gather) ... without the no pre-fetch restriction (the whole list of IDAL addresses can be prefetched ... eliminating the latency for obtaining next data address in the data-chaining scenario).

The issue with shadow CCWs and page crossing shows up in the standard batch os/360 operating systems migrating to virtual memory (analogous to the issue for virtual machine simulation with shadow CCWs). The OS/360 convention has channel programs created by application programs and then call to the kernel for the CCW execution. In os/360 move to virtual memory, the application built CCWs would all have virtual addresses ... the kernel call routine (EXCP0) now had to create shadow channel program where real addresses were substituted for the application virtual addresses ... and in fact, the original os/360 EXCP0 implementation for virtual memory involved "borrowing" the CP67 routine (CCWTRANS) and hacking it for use in os/360 kernel.

So we roll forward to 3033 ... the main os/360 batch system was OS/VS2 MVS ... with separate virtual address space for each application. The 3033 was approx. 4.5mip processor but was limited to both 24bit real and 24bit virtual addresses. Because of the enormous bloat of the MVS system, the real 24bit implementation (16mbyte) was resulting in performance bottleneck. A hack was done to support 64mbyte real storage .... even with 24bit real&virtual instruction addressing limitation; the half-word (16bit) pagetable entry had two spare, undefined bits; 12bit page number (4kbyte pages, 16mbyte real), 2 flag bits, 2 undefined bits. The 2 undefined bits were redefined to prefix the 12bit real page number ... allowing specification of 14bit real page number (16,384 4kbyte real pages, 64mbyte). 24bit virtual address then could be translated into 26bit real address ... even tho instructions (real or vritual) couldn't generate more than 24bit addresses. Full-word IDALs then could be used for I/O transfers into the >16mbyte area ... and virtual pages could reside in the >16mbyte area. There was still lots of stuff that had to reside in the <16mbyte area (including all CCWs as well as the IDALs themselves).

Then there was whole set of reasons why specific virtual page had to be in the <16mbyte area and process for bringing page from >16mbyte area to <16mbyte area. VM370 originally developed a process where a "bring-down" (from >16mbyte to <16mbyte) involved writing the page to disk and then reading it back (below the 16mbyte line). I sent them a code hack which had two virtual address ... one for the old copy above the line and one for the new copy below the line and did a MOVE/COPY operation (not requiring I/O). It was so trivial, they were astounded that they had never thot of the solution.

old email referencing (much earlier) 16mbyte move hack
https://www.garlic.com/~lynn/2011e.html#email870320

old email about page replacement algorithm getting messed up trying to deal differently with >16mbyte area and <16mbyte area
https://www.garlic.com/~lynn/2010.html#email810821
https://www.garlic.com/~lynn/2011c.html#email860501
https://www.garlic.com/~lynn/2011c.html#email860609
https://www.garlic.com/~lynn/2011c.html#email861014

misc. past posts mentioning the 16mbyte line
https://www.garlic.com/~lynn/2000d.html#82 "all-out" vs less aggressive designs (was: Re: 36 to 32 bit transition)
https://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
https://www.garlic.com/~lynn/2002d.html#57 Hardest Mistake in Comp Arch to Fix
https://www.garlic.com/~lynn/2004e.html#41 Infiniband - practicalities for small clusters
https://www.garlic.com/~lynn/2004f.html#51 before execution does it require whole program 2 b loaded in
https://www.garlic.com/~lynn/2004h.html#25 Why are programs so large?
https://www.garlic.com/~lynn/2004o.html#59 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005.html#34 increasing addressable memory via paged memory?
https://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2005p.html#19 address space
https://www.garlic.com/~lynn/2005q.html#30 HASP/ASP JES/JES2/JES3
https://www.garlic.com/~lynn/2005u.html#44 POWER6 on zSeries?
https://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
https://www.garlic.com/~lynn/2006l.html#2 virtual memory
https://www.garlic.com/~lynn/2006m.html#27 Old Hashing Routine
https://www.garlic.com/~lynn/2006w.html#23 Multiple mappings
https://www.garlic.com/~lynn/2007g.html#59 IBM to the PCM market(the sky is falling!!!the sky is falling!!)
https://www.garlic.com/~lynn/2007r.html#56 CSA 'above the bar'
https://www.garlic.com/~lynn/2008f.html#12 Fantasy-Land_Hierarchal_NUMA_Memory-Model_on_Vertical
https://www.garlic.com/~lynn/2009g.html#71 308x Processors - was "Mainframe articles"
https://www.garlic.com/~lynn/2009g.html#74 308x Processors - was "Mainframe articles"
https://www.garlic.com/~lynn/2009l.html#67 ACP, One of the Oldest Open Source Apps
https://www.garlic.com/~lynn/2010.html#84 locate mode, was Happy DEC-10 Day
https://www.garlic.com/~lynn/2010g.html#36 16:32 far pointers in OpenWatcom C/C++
https://www.garlic.com/~lynn/2010l.html#6 Z/OS 31bit or 64bit
https://www.garlic.com/~lynn/2010l.html#32 OS idling
https://www.garlic.com/~lynn/2011c.html#90 A History of VM Performance
https://www.garlic.com/~lynn/2011e.html#27 Multiple Virtual Memory
https://www.garlic.com/~lynn/2011k.html#87 'smttter IBMdroids
https://www.garlic.com/~lynn/2011p.html#126 Deja Cloud?
https://www.garlic.com/~lynn/2012h.html#57 How will mainframers retiring be different from Y2K?

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 06 Mar 2013 13:04:03 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
old email about page replacement algorithm getting messed up trying to deal differently with >16mbyte area and <16mbyte area
https://www.garlic.com/~lynn/2010.html#email810821
https://www.garlic.com/~lynn/2011c.html#email860501
https://www.garlic.com/~lynn/2011c.html#email860609
https://www.garlic.com/~lynn/2011c.html#email861014


re:
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?

for other topic drift ... above was trying to even the global LRU replacement/push pressure on pages below and above the 16mbyte line ... other recent posts mentioning global LRU
https://www.garlic.com/~lynn/2013b.html#11 what makes a computer architect great?
https://www.garlic.com/~lynn/2013c.html#17 I do not understand S0C6 on CDSG

references co-worker of Jim Gray working on stanford PHD related to Global LRU ... and heavy lobby against granting the PHD by the Local LRU forces. Jim asks me to step in since he knew I had worked on Global LRU going back to my undergraduate days in the 60s (about same time that the Local LRU ACM paper appeared). I actually had some direct cp67 comparison data for both global & local replacement ... showing global significantly better.

ibm research management refused to let me send response for nearly a year (this was about the time I was being blamed for online computer conferencing on the internal network ... so possibly it was a form of punishment rather than research management taking sides in the academic dustup over local & global LRU).

Jim had originally made the request at sigops meeting, dec1981 ... but I wasn't allowed to send a response until the following oct.
https://www.garlic.com/~lynn/2006w.html#email821019

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 06 Mar 2013 16:27:05 -0500
Peter Flass <Peter_Flass@Yahoo.com> writes:
I suspect that the bigger problem was self-modifying channel programs. IIRC this was simulated for OS/ISAM and not supported for anything else.

re:
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#49 What Makes an Architecture Bizarre?

most of ISAM wasn't modifying CCWs thenselves ... but the search/seek arguments to the CCWs (arm, head, record positioning) ... prefetch prohibition could be that either the immediately previous read CCW was for the actual following CCW ... but it could also be that the following CCW was there but the previous read was the seek &/or search argument for the following CCW ... which was the case for ISAM.

cp67 virtual machine channel program translation also supported virtual "mini-disks" (multiple virtual disks mapped on a single physical disk) .... as a result it shadowed/translated CCW seek arguments.

Eventually there was an option for ISAM that set full-pack minidisk and/or attached disk (dedicated device) that bypassed arm seek shadow and seek translation ... i.e. for full-pack minidisk (and/or dedicated/attached disk) ... the seek argument for the real/shadowed CCW was in virtual memory ... at the location where a prior CCW read might modify the data.

Basically 360 ISAM kept the index structure on disk and with careful channel CCW programming ... read/follow the structure from disk and operate on it w/o any 360 instruction operation. It would burn an enormous about of channel I/O capacity at the savings of real storage.

There are other examples of the (real storage/channel i/o) trade-off with multi-track searches ... the index is on disk and there is full-cylinder search done by the channel program looking for match (example on 3330 with 3cylinder pds directory ... avg. depth of search is cylinder & half ... two separate i/os, first one 19revolutions or about 1/3rd sec elapsed and 2nd 9.5 revoluations or 1/6th sec elapsed ... total 1/2sec elapsed for two disk i/os).

Starting around the mid-70s the trade-off had inverted ... but lots of the characteristics continue to this day with CKD disks (or at lease requirement for simulated CKD disks; real CKD disks haven't been manufactured for decades).

In the late 70s, I would be brought into large POK batch favorite son operating system shops that were having severe throughput problems ... only to diagnose bottleneck as PDS directory searches (large multi-system operation and the number of application program loads was bottlenecked at 2/sec ... across all systems in the configuration because they were sharing a single, large application program library). Trivial example was large national retailer with hundreds of stores and throughput of large number of systems in large datacenter was 2/sec).

misc. past posts mentioning 360s real storage/channel i/o resource trade-off that had quickly inverted ... but once the paradigm had been established ... it continues to exist today
https://www.garlic.com/~lynn/submain.html#dasd

OS/VS2 (SVS&MVS) eventually had to do something similar for the terminal I/O infrastructure which did have dynamically changing the channel program CCWs. In this case, the application would call for its I/O virtual pages to be "fixed" in real storage ... and then when it built its channel program CCWs ... it would substitute real addresses for virtual addresses ... and then it would use a new kernel call EXCPVR (bypass channel program translation, application had to have authority to use the EXCPVR call) in place of the EXCP call (which would build shadow channel program with translated CCWs).

misc. past posts mentioning EXCPVR
https://www.garlic.com/~lynn/2007q.html#8 GETMAIN/FREEMAIN and virtual storage backing up
https://www.garlic.com/~lynn/2007s.html#2 Real storage usage - a quick question
https://www.garlic.com/~lynn/2008i.html#68 EXCP access methos
https://www.garlic.com/~lynn/2011p.html#118 Start Interpretive Execution
https://www.garlic.com/~lynn/2012n.html#19 How to get a tape's DSCB
https://www.garlic.com/~lynn/2012n.html#21 8-bit bytes and byte-addressed machines

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 06 Mar 2013 16:51:30 -0500
hancock4 writes:
According to the "System/370 Summary" of Feb 1975, the largest memory available was 8 meg. (Oddly, the model 195 was maxed at 4 meg).

I suppose organizations that needed more memory than that to support large on-line processing had to get multiple processors. For batch processing, 8 meg is very large for a single application.


mention trying to provide more than 16mbyte real storage for 3033
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#49 What Makes an Architecture Bizarre?

OS/VS2 started out with SVS ... basically the old real-storage MVT layed out in single 16mbyte virtual address space. Number of applications could be greater than what MVT was able to do in straight real storage size (note that this have been previously simulated under CP67 and VM370 with 16mbyte virtual machine size) ... and as previously mentioned initial OS/VS2 even borrowed CP67 CCWTRANS to do the channel program translation in the kernel EXCP processing

this is old post discussing some of the considerations of OS/VS2 ... including part of the justification for moving all 370 from real to virtual ... part of the consideration was that standard MVT application storage management required reserving peak possible required as single contiguous area ... but typical applications used less than 1/4 that space. Virtual memory would allow approx. four times as many concurrent applications (overlapping execution with growing disk i/o bottleneck) getting greater aggregate throughput
https://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

In the move from OS/VS2 SVS (single 16mbyte virtual address space) to MVS (separate 16mbyte virtual address space for each application), there were a couple of gatchas. The os/360 real storage heritage was exceedingly pointer passing API ... as a result MVS actually mapped and image of the MVS kernel into 8mbytes of every application 16mbyte virtual address space (so pointer-passing API kernel calls could access, manipulate and return application data).

os/360 heritage also had numerous "subsystems" that resided outside the kernel ... but were called by applications with pointer passing API ... in transition to MVS, these now occupied separate virtual address spaces. In preserving the pointer-passing API, a 1mbyte "common segment" was greated that occupied every virtual address space ... where data could be passed back & forth with subsystems using pointer-passing API. This started out limiting application address space to 7mbytes. However, the common segment morphed into the common system area (CSA) ... since its size needed to be proportional to the number of concurrent applications and subsystems that would be using the area. In the 3033 time-frame this was usually on the order of 4-5mbytes for most large 3033 MVS installations and threatend to grow to 5 or 6mbytes (leaving some installations with max of only 2mbytes for application).

At one point, there was a large internal loyal MVS batch installation in Burlington VT ... that ran large fortran design applications around the clock in multiple carefully constructed MVS systems with CSA limited to one megabyte ... leaving "full" 7mbyte for the fortran applications. This fortran applications were constantly in danger of exceeding 7mbytes ... and at one point they were faced with converting all of their machines to vm370/cms ... since nearly a full 16mbyte virtual address space could be made available for their large number of fortran runs.

some recent posts mentioning MVS common segment (common system area) kludge:
https://www.garlic.com/~lynn/2011.html#79 Speed of Old Hard Disks - adcons
https://www.garlic.com/~lynn/2011b.html#20 A brief history of CMS/XA, part 1
https://www.garlic.com/~lynn/2011d.html#72 Multiple Virtual Memory
https://www.garlic.com/~lynn/2011f.html#17 New job for mainframes: Cloud platform
https://www.garlic.com/~lynn/2011h.html#11 History of byte addressing
https://www.garlic.com/~lynn/2011k.html#11 Was there ever a DOS JCL reference like the Brown book?
https://www.garlic.com/~lynn/2011l.html#45 segments and sharing, was 68000 assembly language programming
https://www.garlic.com/~lynn/2012b.html#66 M68k add to memory is not a mistake any more
https://www.garlic.com/~lynn/2012b.html#100 5 Byte Device Addresses?
https://www.garlic.com/~lynn/2012e.html#80 Word Length
https://www.garlic.com/~lynn/2012h.html#57 How will mainframers retiring be different from Y2K?
https://www.garlic.com/~lynn/2012i.html#53 Operating System, what is it?
https://www.garlic.com/~lynn/2012j.html#26 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
https://www.garlic.com/~lynn/2012j.html#27 Simulated PDP-11 Blinkenlight front panel for SimH
https://www.garlic.com/~lynn/2012l.html#75 PDP-10 system calls, was 1132 printer history
https://www.garlic.com/~lynn/2012n.html#21 8-bit bytes and byte-addressed machines
https://www.garlic.com/~lynn/2012o.html#30 Regarding Time Sharing

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 06 Mar 2013 17:10:14 -0500
hancock4 writes:
According to the "System/370 Summary" of Feb 1975, the largest memory available was 8 meg. (Oddly, the model 195 was maxed at 4 meg).

I suppose organizations that needed more memory than that to support large on-line processing had to get multiple processors. For batch processing, 8 meg is very large for a single application.


re:
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#49 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#51 What Makes an Architecture Bizarre?

oh, and around the mid-70s, I started to point out that the CKD paradigm from the 60s trading off abundant channel & disk i/o resources against scarce real storage was starting to invert ... and increasingly plentiful real storage was being used to compensate for increasingly limited i/o throughput.

early 80s, I was starting to say that in the period in the 60s with cp67 & 360/67 to vm370 & 3081, processor & real-storage resources had increased by a factor of 40-50 while disk i/o had only increased by 4-5 (i.e. relative system disk i/o throughput had declined by an order of magnitude during the period) ... past posts with old cp67/vm370 I/O system comparison
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#43 Bloat, elegance, simplicity and other irrelevant concepts
https://www.garlic.com/~lynn/94.html#55 How Do the Old Mainframes Compare to Today's Micros?
https://www.garlic.com/~lynn/95.html#10 Virtual Memory (A return to the past?)
https://www.garlic.com/~lynn/98.html#46 The god old days(???)
https://www.garlic.com/~lynn/99.html#4 IBM S/360

Some disk division executives took exception to my assertions and assigned the division performance group to refute my statements; after a few weeks they came back and essentially said I had slightly understated the problem. Their analysis then morphs into user group presentation on managing disks to improve system throughput
https://www.garlic.com/~lynn/2006f.html#3 using 3390 mod-9s
https://www.garlic.com/~lynn/2006o.html#68 DASD Response Time (on antique 3390?)

other past posts with refs:
https://www.garlic.com/~lynn/2002i.html#18 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2002i.html#46 AS/400 and MVS - clarification please
https://www.garlic.com/~lynn/2007s.html#5 Poster of computer hardware events?
https://www.garlic.com/~lynn/2009g.html#71 308x Processors - was "Mainframe articles"
https://www.garlic.com/~lynn/2009i.html#7 My Vintage Dream PC
https://www.garlic.com/~lynn/2009k.html#34 A Complete History Of Mainframe Computing
https://www.garlic.com/~lynn/2009k.html#52 Hercules; more information requested
https://www.garlic.com/~lynn/2009l.html#67 ACP, One of the Oldest Open Source Apps
https://www.garlic.com/~lynn/2010c.html#1 "The Naked Mainframe" (Forbes Security Article)
https://www.garlic.com/~lynn/2010h.html#70 25 reasons why hardware is still hot at IBM
https://www.garlic.com/~lynn/2010l.html#31 Wax ON Wax OFF -- Tuning VSAM considerations
https://www.garlic.com/~lynn/2010l.html#32 OS idling
https://www.garlic.com/~lynn/2010l.html#33 History of Hard-coded Offsets
https://www.garlic.com/~lynn/2010n.html#18 Mainframe Slang terms
https://www.garlic.com/~lynn/2011.html#35 CKD DASD
https://www.garlic.com/~lynn/2011.html#61 Speed of Old Hard Disks
https://www.garlic.com/~lynn/2011e.html#1 Multiple Virtual Memory
https://www.garlic.com/~lynn/2011p.html#5 Why are organizations sticking with mainframes?
https://www.garlic.com/~lynn/2011p.html#32 Has anyone successfully migrated off mainframes?
https://www.garlic.com/~lynn/2012b.html#73 Tape vs DASD - Speed/time/CPU utilization
https://www.garlic.com/~lynn/2012e.html#39 A bit of IBM System 360 nostalgia
https://www.garlic.com/~lynn/2012o.html#62 ISO documentation of IBM 3375, 3380 and 3390 track format

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 06 Mar 2013 21:00:28 -0500
hancock4 writes:
Would you recall what the Fortran application was that was so large to require 7 megbytes? That seems really, really big. Was it one single giant program or multiple programs running at once?

re:
https://www.garlic.com/~lynn/2013c.html#51 What Makes an Architecture Bizarre?

they had large chip design and board layout applications written in fortran ... old email reference
https://www.garlic.com/~lynn/2006b.html#email800310
in this post
https://www.garlic.com/~lynn/2006b.html#39 another blast from the past

I don't know the details of that particular app ... probably combination of lots of fortran routines ... plus large datastructures that had to be operated on (representing chip circuits and/or board layout).

I've mentioned recently getting to port a Los Gatos VLSI app written in VS/Pascal (after the company going into the red in the early 90s (with company being restructured into the "baby blues" for breakup), then Gerstner being brought in to resurrect the company ... there was decision to move to commercial (COTS) chip/board applications. Part of that involved porting some number of the internal design applications to industry standard platforms and technology transfers to some software design application companies) ... that was over 50k statements pascal
https://www.garlic.com/~lynn/2013b.html#21 New HD
https://www.garlic.com/~lynn/2013b.html#60 New HD
https://www.garlic.com/~lynn/2013b.html#71 New HD

this is similar but different old email about San Jose MVS-based MDS (micro design system for disk controllers). the issue here was that their large datacenters were starting to burst at the seams with trying to add ever more 3033s.
https://www.garlic.com/~lynn/2006v.html#email800717
https://www.garlic.com/~lynn/2006p.html#email810128

this was part of the leading wave of 4341s being put out in conference rooms and departmental supply rooms ... booming explosion in distributed 4341s. For wide variety of reasons the internal large explosion in number of 4341s were nearly all vm370 (small physical footprint, significantly reduced environmental requirements ... not needing expensive datacenter, typical mvs system would require 20-30 support people, not practical for a dedicated department machine).

not just internal ... but starting to be customers also old email about doing vm370/cms fortran rain/rain4 6600 benchmarks for national lab looking at possibly getting compute farm of 70 4341s (depending on benchmark results and if price comes in under $300k)
https://www.garlic.com/~lynn/2006y.html#email790212
https://www.garlic.com/~lynn/2006y.html#email790212b
https://www.garlic.com/~lynn/2006y.html#email790220
https://www.garlic.com/~lynn/2006y.html#email790226

in this old post
https://www.garlic.com/~lynn/2006y.html#21

4341 was 36.13/36.51secs (compared to originally 35.77secs on 6600)

other old 4300 email
https://www.garlic.com/~lynn/lhwemail.html#43xx

--
virtualization experience starting Jan1968, online at home since Mar1970

NBC's website hacked with malware

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NBC's website hacked with malware
Newsgroups: alt.folklore.computers
Date: Wed, 06 Mar 2013 21:51:49 -0500
Rob Doyle <radioengr@gmail.com> writes:
Hopefully was deliberately altered information like the Concordsky...

re:
https://www.garlic.com/~lynn/2013b.html#68 NBC's website hacked with malware

also mentioned in this (closed linkedin) Information Security
https://www.garlic.com/~lynn/2013b.html#62 America Is Basically Helpless Against The Chinese Hackers

doesn't need to be deliberately altered information ... could be original ... recent post over in facebook boyd&beyond
Chuck Spinney: Treason Thy Name is F-35A aka "Acquisition Malpractice"
http://www.phibetaiota.net/2013/03/chuck-spinney-treason-thy-name-is-f-35a-aka-acquisition-malpractice/

references this Aug2000 in Proceedings of the Naval Institute by Chuck

The JSF: One More Card In The House
http://dl.dropbox.com/u/52781209/Tactical%20Fighters/JSF-%20One%20More%20Card%20in%20the%20H.pdf

also references:

Winslow Wheeler: Treason Thy Name is F-35A -- We Expect Hagel to "Do A Cheney"
http://www.phibetaiota.net/2013/03/winslow-wheeler-treason-they-name-is-f-35a-we-expect-hagel-to-do-a-cheney/

references:

Review: Prophets of War -- Lockheed Martin and the Making of the Military-Industrial Complex
http://www.phibetaiota.net/2011/01/review-prophets-of-war-lockheed-martin-and-the-making-of-the-military-industrial-complex/

which is about:

Prophets of War: Lockheed Martin and the Making of the Military-Industrial Complex
https://www.amazon.com/Prophets-War-Lockheed-Military-Industrial-ebook/dp/B0047T86BA/

other references:

CRS Report for Congress; Prepared for Members and Committees of Congress F-35 Joint Strike Fighter (JSF) Program
http://www.fas.org/sgp/crs/weapons/RL30563.pdf


.... snip ...

started with this ...
time cover article 30yrs ago
http://nation.time.com/2013/02/28/it-was-30-years-ago-today/

from the "A Matter of Mindset" thread ... Boyd spent a large amount of time on this subject. He commented that they spent 18 months on strategy and collecting written approval to provide Spinney cover for this 1983 "The Winds of Reform" article in time
https://web.archive.org/web/20070320170523/http://www.time.com/time/magazine/article/0,9171,953733,00.html
also
https://content.time.com/time/magazine/article/0,9171,953733,00.html

Boyd would say when SECDEF found that he couldn't put Spinney in jail, he attempted to have Boyd banned from the Pentagon (for life) as being behind the whole thing. Boyd would tell the story that lead up to the article was congressional hearing the week before. DOD forces got the hearing moved to friday afternoon and the room where watergate hearing was held (about the smallest they could find) as part of trying to minimize news coverage. Supposedly Pentagon/SECDEF held damage assessment conference on Saturday and found very few references. They were apparently blind-sided when the Time magazine cover article dropped in on Monday.

A co-worker (at IBM) tracked down Spinney's phone number (after seeing the article) and called him up .... Spinney suggested he talk to Boyd instead. He called John and John offered to give his brief ... and I got roped into sponsoring John's briefings at IBM. He was still in the process of developing Organic Design for Command and Control ... so the first briefing was just Patterns Of Conflict ... but a few months later ... for the 2nd briefing he crammed Patterns Of Conflict and Organic Design for Command and Control into a single day.


... snip ...

and from Chuck's blaster

Buy Before You Fly ... or ... How to Suck Money During the Politics of Austerity
http://chuckspinney.blogspot.com/2013/03/buy-before-you-fly-or-how-to-suck-money.html
More on the F-35's Concurrency Shop of Horrors
http://chuckspinney.blogspot.com/2013/03/more-on-f-35s-concurrency-shop-of.html

more references:

More F-35 Turbulence
http://nation.time.com/2013/03/06/more-f-35-turbulence/
The Air Force's F-35A: Not Ready for Combat, Not Even Ready for Combat Training
http://www.pogo.org/blog/2013/03/20130306-air-forces-f-35a-not-ready-for-combat.html
Pentagon report warns of F-35 visibility risks
http://www.marinecorpstimes.com/news/2013/03/dn-pentagon-report-warns-of-f35-visibility-risks-030613/

theme from Chet (another of Boyd's acolytes)

This just in -- military force not that useful any more
http://slightlyeastofnew.com/2013/03/06/this-just-in-military-force-not-that-useful-any-more/

there is line about Generals always preparing to (re)fight the last war

Pentagon cyberdefenses weak, report warns
http://www.washingtonpost.com/world/national-security/pentagon-cyberdefenses-weak-report-warns/2013/03/05/b0c8af5a-8504-11e2-999e-5f8e0410cb9d_story.html

misc. past posts mentioning Boyd
https://www.garlic.com/~lynn/subboyd.html

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 6 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
regarding Volcker rule implementation: Goldman Sachs Is Looking For A Volcker Rule Loophole
http://compliancex.com/goldman-sachs-is-looking-for-a-volcker-rule-loophole/

The Government Has It Bass-Ackwards: Failing To Prosecute Criminal Fraud by the Big Banks Is Killing -- NOT Saving -- the Economy
http://www.nakedcapitalism.com/2013/03/washingtons-blog-the-government-has-it-bass-ackwards-failing-to-prosecute-criminal-fraud-by-the-big-banks-is-killing-not-saving-the-economy.html

from above:

If the big banks were important to the economy, would so many prominent economists, financial experts and bankers be calling for them to be broken up?

If the big banks generated prosperity for the economy, would they have to be virtually 100% subsidized to keep them afloat?

If the big banks were helpful for an economic recovery, would they be prolonging our economic instability?

In fact, failing to prosecute criminal fraud has been destabilizing the economy since at least 2007 ... and will cause huge crashes in the future.


... snip ... and

Postscript: Unfortunately, the government made it official policy not to prosecute fraud, even though criminal fraud is the main business model adopted by the giant banks.

Indeed, the government has done everything it can to cover up fraud, and has been actively encouraging criminal fraud and attacking those trying to blow the whistle.


... snip ...

aka

The Real Reason Wall Street Always Escapes Criminal Charges? The Justice Dept Fears The Aftermath
http://www.forbes.com/sites/halahtouryalai/2013/03/06/the-real-reason-wall-street-always-escapes-criminal-charges-the-justice-dept-fears-the-aftermath/

from above:
The notion of too big to jail just got very serious as the nation's chief attorney agreed with the idea that financial institutions are too large to prosecute.

... snip ...

leaves lots of room for speculation that the agencies are "captured" and are acting in the interest of those institutions

recent posts in this thread:
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#5 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#26 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#42 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Thu, 07 Mar 2013 08:08:33 -0500
Terje Mathisen <"terje.mathisen at tmsw.no"> writes:
Even _perl_ is an order of magnitude better than COBOL for data processing, including any possible combination of fp, integer and ascii/bcd numeric values...

one of the early cp67 spin-offs from science center was NCSS offering cp67 commerical online time-sharing ... early offering was 4GL RAMIS (from Mathematica)
https://en.wikipedia.org/wiki/Ramis_software

RAMIS oral history ... one of the RAMIS developrs leaves and develops FOCUS ... which is offered on Tymshare commercial online vm370 service (official cp67 having morphed into vm370)
http://archive.computerhistory.org/resources/access/text/Oral_History/102658228.05.01.acc.pdf

NCSS enhances their cp67 to run on 370s (VPSS). NCSS develops its own proprietary NOMAD (NCSS Owned, Maintained And Developed)
https://en.wikipedia.org/wiki/Nomad_software

from above:
Another example of Nomad's power is illustrated by Nicholas Rawlings in his comments for the Computer History Museum about NCSS (see citation below). He reports that James Martin asked Rawlings for a Nomad solution to a standard problem Martin called the Engineer's Problem: "give 6% raises to engineers whose job ratings had an average of 7 or better." Martin provided a "dozen pages of COBOL, and then just a page or two of Mark IV, from Informatics." Rawlings offered the following single statement, performing a set-at-a-time operation, to show how trivial this problem was with Nomad:

CHANGE ALL SALARY=SALARY*1.06 WHERE POSITION='ENG' AND AVG(INSTANCE(RATING)) GE 7


... snip ...

A Brief History of Fourth Generation Languages
http://www.decosta.com/Nomad/tales/history.html

other trivia ... original relational/sql implementation was on vm370 system on ibm san jose research ... some past posts
https://www.garlic.com/~lynn/submain.html#systemr

recent post discussing shared/protected virtual segments versus shared/protected pages. DWSS were vm370 changes so some system/r virtual address spaces could have r/w shared segment access and other system/r virtual address spaces were restricted to r/o access to the same shared segments
https://www.garlic.com/~lynn/2013c.html#32 REFRPROT History Question
https://www.garlic.com/~lynn/2013c.html#37 PDP-10 byte instructions, was What Makes an Architecture Bizarre?

misc. past posts mentioning (virtual machine based) commercial online time-sharing:
https://www.garlic.com/~lynn/submain.html#timeshare

misc. past posts mentioning nomad and/or ramis:
https://www.garlic.com/~lynn/2002i.html#64 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002i.html#69 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002l.html#56 10 choices that were critical to the Net's success
https://www.garlic.com/~lynn/2003d.html#15 CA-RAMIS
https://www.garlic.com/~lynn/2003d.html#17 CA-RAMIS
https://www.garlic.com/~lynn/2003k.html#48 Who said DAT?
https://www.garlic.com/~lynn/2003n.html#12 Dreaming About Redesigning SQL
https://www.garlic.com/~lynn/2003n.html#15 Dreaming About Redesigning SQL
https://www.garlic.com/~lynn/2004e.html#15 Pre-relational, post-relational, 1968 CODASYL "Survey of Data Base Systems"
https://www.garlic.com/~lynn/2004j.html#52 Losing colonies
https://www.garlic.com/~lynn/2004l.html#44 Shipwrecks
https://www.garlic.com/~lynn/2006k.html#35 PDP-1
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2007c.html#12 Special characters in passwords was Re: RACF - Password rules
https://www.garlic.com/~lynn/2007e.html#37 Quote from comp.object
https://www.garlic.com/~lynn/2007j.html#17 Newbie question on table design
https://www.garlic.com/~lynn/2007o.html#38 It's No Secret: VMware to Develop Secure Systems for NSA
https://www.garlic.com/~lynn/2007u.html#87 CompUSA to Close after Jan. 1st 2008
https://www.garlic.com/~lynn/2008s.html#66 Computer History Museum
https://www.garlic.com/~lynn/2009k.html#40 Gone but not forgotten: 10 operating systems the world left behind
https://www.garlic.com/~lynn/2010e.html#54 search engine history, was Happy DEC-10 Day
https://www.garlic.com/~lynn/2010e.html#55 Senior Java Developer vs. MVS Systems Programmer (warning: Conley rant)
https://www.garlic.com/~lynn/2010e.html#58 Senior Java Developer vs. MVS Systems Programmer (warning: Conley rant)
https://www.garlic.com/~lynn/2010n.html#21 What non-IBM software products have been most significant to the mainframe's success
https://www.garlic.com/~lynn/2010o.html#26 Global Sourcing with Cloud Computing and Virtualization
https://www.garlic.com/~lynn/2010q.html#63 VMSHARE Archives
https://www.garlic.com/~lynn/2011d.html#55 Maybe off topic
https://www.garlic.com/~lynn/2011m.html#69 "Best" versus "worst" programming language you've used?
https://www.garlic.com/~lynn/2011p.html#1 Deja Cloud?
https://www.garlic.com/~lynn/2012b.html#60 Has anyone successfully migrated off mainframes?
https://www.garlic.com/~lynn/2012d.html#51 From Who originated the phrase "user-friendly"?
https://www.garlic.com/~lynn/2012e.html#84 Time to competency for new software language?
https://www.garlic.com/~lynn/2012n.html#30 General Mills computer

--
virtualization experience starting Jan1968, online at home since Mar1970

Article for the boss: COBOL will outlive us all

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Article for the boss: COBOL will outlive us all
Newsgroups: bit.listserv.ibm-main
Date: 7 Mar 2013 06:10:38 -0800
re:
https://www.garlic.com/~lynn/2013c.html#11 Article for the boss: COBOL will outlive us all

more cobol related trivia ... other spin-offs from the science center were companies that started offering cp67 as commercial online service ... recent post in a.f.c
https://www.garlic.com/~lynn/2013c.html#56

regarding RAMIS, NOMAD, FOCUS, etc ... i.e. original 4th gen languages ... all done on virtual machine (cp67 or vm370 based) online services

nomad wiki
https://en.wikipedia.org/wiki/Nomad_software

from above:

Another example of Nomad's power is illustrated by Nicholas Rawlings in his comments for the Computer History Museum about NCSS (see citation below). He reports that James Martin asked Rawlings for a Nomad solution to a standard problem Martin called the Engineer's Problem: "give 6% raises to engineers whose job ratings had an average of 7 or better." Martin provided a "dozen pages of COBOL, and then just a page or two of Mark IV, from Informatics." Rawlings offered the following single statement, performing a set-at-a-time operation, to show how trivial this problem was with Nomad:

CHANGE ALL SALARY=SALARY*1.06 WHERE POSITION='ENG' AND AVG(INSTANCE(RATING)) GE 7


... snip ...

other trivia was that the original relational/sql was also done on vm370 ... mentioned in this recent post
https://www.garlic.com/~lynn/2013c.html#32 REFRPROT History Question

--
virtualization experience starting Jan1968, online at home since Mar1970

More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
Date: 7 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
Whistleblower: Wells Fargo Fabricated and Altered Mortgage Documents on a Mass Basis
http://www.nakedcapitalism.com/2013/03/whistleblower-wells-fargo-fabricated-mortgage-documents-on-a-mass-basis.html

from above:
A contractor who worked at a Wells Fargo facility in Minnesota reports that the bank engaged in systematic, large scale alteration of mortgage notes and fabrication of related documents in preparation for foreclosure. The procedures the bank used are questionable for a large portion of the mortgages.

A team of roughly 100 temps divided across two shifts would review borrower notes (the IOU) to see whether they met a set of requirements the bank set up. Any that did not pass (and notes in securitized trusts were almost always failed) went to another unit in the same facility. They would later come back to the review team to check if the fixes and fabrications had been done correctly.


... snip ...

other recent posts in this discussion
https://www.garlic.com/~lynn/2013.html#41 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013.html#73 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#16 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#27 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#36 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#47 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#64 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013b.html#70 Implementing a Whistle-Blower Program - Detecting and Preventing Fraud at Workplace
https://www.garlic.com/~lynn/2013c.html#6 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#19 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence
https://www.garlic.com/~lynn/2013c.html#43 More Whistleblower Leaks on Foreclosure Settlement Show Both Suppression of Evidence and Gross Incompetence

--
virtualization experience starting Jan1968, online at home since Mar1970

Why Intel can't retire X86

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why Intel can't retire X86
Newsgroups: alt.folklore.computers
Date: Thu, 07 Mar 2013 10:57:22 -0500
hancock4 writes:
Seems no different than S/360, which will be 50 y/o next year. (Actually, it's probaby 50 now since I think they worked out the architecture after the SPREAD report in 1962-63.)

IBM tried to kill off S/360 with Future System, and that was a bust, just like the Intel efforts were.

I suspect x86 will be around for a long time to go for the same reason S/360 ain't going nowhere--too much investment in software is out there.


misc. past fs posts
https://www.garlic.com/~lynn/submain.html#futuresys

after FS, I've claimed that John did risc/801 ... in part to go to the opposite extreme of the horrible complexity in FS (motivated in part to significantly raise the bar against clone controllers and processors).

late 70s through early 80s, company had program to converge the large number of different corporate microprocessors to 801/risc ... including all the native engines used in entry and mid-range 370s, the as/400 (follow-on to s/38), controllers, lots of others. misc. past 801/risc posts (for various reasons these efforts mostly floundered and you see engineers leaving to work on risc at other vendors)
https://www.garlic.com/~lynn/subtopic.html#801

risc has pioneered lots of hardware performance going back at least 30yrs

recently the claim is that the last several x86 generation chips have been risc cores with hardware layer than translate x86 instructions to risc micro-ops for execution ... significantly narrowing the performance difference between risc & x86. a poster child for this has been e5-2600 with two 8-core chips and 527BIPS rating (33BIPS/processor).

the most recent couple generations of 370 (z) have also claimed that at least half of the processor performance improvement from z10 to z196 and then from z196 to ec12 has been because of incorporating features that have been in risc for decades (like out-of-order execution to help mitigate execution stream stalling because of cache misses).

z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012


--
virtualization experience starting Jan1968, online at home since Mar1970

Why Intel can't retire X86

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Why Intel can't retire X86
Newsgroups: alt.folklore.computers
Date: Thu, 07 Mar 2013 14:22:22 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012


re:
https://www.garlic.com/~lynn/2013c.html#59 Why Intel can't retire X86

IBM has had base list price of $1815 for e5-2600 blade ... or about $3.44/BIPS. Major cloud operators have claimed they build their own blades for about 1/3rd the cost of brand name blades (possibly around $1/BIPS).

z900 to z10 goes from 156MIPS/proc to 469MIPS/proc in little less than 8yrs ... about factor of three times. From z10 to ec12 is 469MIPS to 743MIPS (in little over 4yrs) ... nearly 60% improvement ... over half supposedly attributed to adding risc-like operational features like out-of-order execution.

80 processor z196 goes for $28M or $560,000/BIPS. there has been recent IBM news that 4% of IBM revenue is from mainframe processors ... while 25% is total mainframe related revenue (including software, services, storage) ... aka about avg 6.25 times multiplier of the base processor price ... or for $28M z196 that would come closer to $175M total ... or $3.5M/BIPS (compared to possibly $1/BIPS for cost of e5-2600 at cloud vendor). I have yet to see the corresponding price for 101 processor ec12.

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 8 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
Justice defending not prosecuting criminal too-big-to-fail while also defending their "disproportionate" charges against Aaron Swartz (50+yrs jail time)

Congresswoman Proposes "Aaron's Law" in Honor Of Late Internet Activist
http://techcrunch.com/2013/01/15/congresswoman-proposes-aarons-law-in-honor-of-late-internet-activist/

from above:
Prosecution against Swartz was apparently so aggressive that MIT has ordered an investigation into the handling of the case.

... snip ...

Swartz's Girlfriend Shares Intimate Details Of His Last Days, Explains "Why Aaron Died"
http://techcrunch.com/2013/02/04/swartzs-girlfriend-shares-intimate-details-of-his-last-days-explains-why-aaron-died/

from above:

Placing the blame on mental health, she argues, diverts attention from the true cause of his suicide: an overzealous prosecution


... snip ...

Elizabeth Warren Savaged A Treasury Official During A Hearing On HSBC's International Money Laundering Scandal
http://www.businessinsider.com/elizabeth-warren-hsbc-money-laundering-2013-3

references from last summer

Monster Report On HSBC Money Laundering Reads Like A James Bond Villain's Master Plan
http://www.businessinsider.com/hsbc-money-laundering-report-2012-7

How Many Billions Of Drug-Laundered Money Does It Take To Shut Down A Bank?
http://www.zerohedge.com/news/2013-03-07/how-many-billions-drug-laundered-money-does-it-take-shut-down-bank

ongoing TBTJ theme in hearings

Treasury and Fed Officials Prevaricate Before Elizabeth Warren About Whether They Will Ever Get Tough With Banks
http://www.nakedcapitalism.com/2013/03/treasury-and-fed-officials-prevaricate-before-elizabeth-warren-about-whether-they-will-ever-get-tough-with-banks.html

another case for too big becoming too complex, too bloated and too difficult to operate

The Growing IT Mess at Big Banks
http://www.nakedcapitalism.com/2013/03/the-growing-it-mess-at-big-banks.html

Why banks are likely to face more software glitches in 2013
http://www.bbc.co.uk/news/technology-21280943

Outrage: Some Banks Are Too Big to Prosecute; Attorney General Eric Holder admits that the biggest banks are not just too big too fail, but above the law.
http://www.alternet.org/outrage-some-banks-are-too-big-prosecute

Elizabeth Warren Wants HSBC Bankers Jailed for Money Laundering
http://abcnews.go.com/blogs/politics/2013/03/elizabeth-warren-wants-hsbc-bankers-jailed-for-money-laundering/
Elizabeth Warren takes off the gloves
http://theweek.com/article/index/241150/elizabeth-warren-takes-off-the-gloves

note that the too-big-to-jail meme had appeared at least by the summer of 2010 when some of the drug cartel money laundering was coming to light.

a take-off on the theme.

The Corrupt US Government: Why US Treasury Officials Refused to Consider Recommending Criminal Charges Against Drug Money Laundering Bankers
http://johnhively.wordpress.com/2013/03/08/the-corrupt-us-government-why-us-treasury-officials-refused-to-consider-recommending-criminal-charges-against-drug-money-laundering-bankers/

cartoon

Banks are not too big to fail: They're infested with rich investors and those are the folks that Obama is terrifed of.
http://johnhively.wordpress.com/2013/03/08/banks-are-not-too-big-to-fail-theyre-infested-with-rich-investors-and-those-are-the-folks-that-obama-is-terrifed-of/

recent posts in this thread:
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#5 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#26 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#42 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#55 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Fri, 08 Mar 2013 11:32:05 -0500
Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
WTF? The fact that you need assistance from the OS to schedule a channel program doesn't mean the architecture was intended to preclude application programs from constructing and manipulating them. I don't regard EXCP as an aberration.

re:
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?

however, in the transition from real to virtual (cp67 had hit it earlier with virtual memory for virtual machines) ... the use of real addresses in CCWs was big issue. The EXCP brick wall between building CCWs and execution of CCWs allowed the insertion (originally CP67's CCWTRANS) into EXCP processing building shadow copy CCWs (with real addresses) for execution (rather than the original channel program passed in the EXCP call).

when Jim Gray was leaving for Tandem, he was palming a bunch of stuff off on me ... including DBMS consulting with the IMS database group. However, I also got sucked into some other work for the IMS group. 1980, STL (santa teresa lab, now SVL, silicon valley lab) was bursting at the seams and 300 people from IMS group was being moved to offsite building and being offered "remote" 3270 service back to the STL datacenter (remote 3270 ran over 19.2kbaud telco lines). They were use to vm370/cms local channel attach 3270 service ... and found the remote 3270 to have intolerable human factors.

I got sucked into doing HYPERchannel channel-extender support for them ... allowing local channel attach 3270s to be placed at the offsite building. HYPERchannel had remote device adapter that simulated mainframe channel. For the channel-extender operation ... the software had to package up the channel program and transmit it to the remote device adapter (i.e. channel program executed out of the remote simulated channel box ... not out of the local mainframe). This resulted in the IMS people at the remote bldg not seeing any difference in human factors (although it was going over a T1/1.5mbit microwave link). It had side affect of improving mainframe computer performance by 10-15% ... since the 3270 controllers were no longer directly attached to real channels ... being replace with HYPERchannel local adapter (that had significantly reduced channel busy operation compared to 3270 controllers for the same operations).

Totally unrelated, about 1988, I got asked to help LLNL work on standardizing some serial technology they had ... that eventually turns into fiber-channel standard (FCS). Later mainframe channel people do some work on layering a extremely heavyweight protocol on top of FCS (that significantly reduces throughput) that comes to be called FICON.

Recently FICON has added an enhancement that downloads channel programs to the remote end ... similar to what I had done for HYPERchannel in 1980 (and similar to what some native FCS does) ... that reduces the FICON throughput penalty ... but still nowhere close to native FCS throughput.

80 z196 processor configuration with (max) 14 System Assist Processors (for i/o assist) getting 2M IOPS (nearly maxing out 14 SAPs that hit 100% with 2.2M SSCH/sec ... although recommendations are to normally run SAPs at 70% utilization or peak 1.5M SSCH/sec)

Recent posts about peak i/o z196 mainframe throughput ... including the channel program package download:
https://www.garlic.com/~lynn/2013.html#10 From build to buy: American Airlines changes modernization course midflight
https://www.garlic.com/~lynn/2013.html#40 Searching for storage (DASD) alternatives
https://www.garlic.com/~lynn/2013.html#77 OT: but hopefully interesting - Million core supercomputer
https://www.garlic.com/~lynn/2013b.html#6 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#7 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#8 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#55 Dualcase vs monocase. Was: Article for the boss

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Fri, 08 Mar 2013 14:08:40 -0500
re:
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#62 What Makes an Architecture Bizarre?

z196 peak i/o with 2M IOPS used 104 FICON (ibm channel emulation on 104 FCS) ... this is compared to recent announcement of a FCS for e5-2600 claiming over 1M IOPS (for a single FCS)

note that the download of channel program CCWs for execution (what i did in 1980 for HYPERchannel channel extender or the more recent stuff for FICON, aka "TCW") is analogous to creating shadow copy of channel program CCWs with real addresses for execution (as opposed to using the channel program CCWs with virtual addresses).

misc. past posts mentioning my HSDT (high-speed data transport) project, including various HYPERchannel activities
https://www.garlic.com/~lynn/subnetwork.html#hsdt

other topic drift misc. past posts mentioning having done RFC1044 support for the mainframe TCP/IP product (getting possibly 500 times improvement in the bytes moved per instruction executed)
https://www.garlic.com/~lynn/subnetwork.html#1044

and even more topic drift ... old post mentioning early Jan92 meeting in Ellison's conference room regarding FCS for 128-way cluster scale-up
https://www.garlic.com/~lynn/95.html#13
and related old email
https://www.garlic.com/~lynn/lhwemail.html#medusa

possibly within hrs of the last email (referenced above), the cluster scale-up was transferred and we were told we couldn't work on anything with more than four processors ... and couple weeks later it was announced as supercomputer.

misc. recent FICON TCW &/or FCS for e5-2600 references
https://www.garlic.com/~lynn/2012m.html#4 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012m.html#5 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012m.html#11 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012m.html#13 Intel Confirms Decline of Server Giants HP, Dell, and IBM
https://www.garlic.com/~lynn/2012m.html#28 I.B.M. Mainframe Evolves to Serve the Digital World
https://www.garlic.com/~lynn/2012m.html#43 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012n.html#19 How to get a tape's DSCB
https://www.garlic.com/~lynn/2012n.html#44 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
https://www.garlic.com/~lynn/2012n.html#51 history of Programming language and CPU in relation to each
https://www.garlic.com/~lynn/2012n.html#70 Under what circumstances would it be a mistake to migrate applications/workload off the mainframe?
https://www.garlic.com/~lynn/2012n.html#72 Mainframes are still the best platform for high volume transaction processing
https://www.garlic.com/~lynn/2012o.html#6 Mainframes are still the best platform for high volume transaction processing
https://www.garlic.com/~lynn/2012o.html#25 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012o.html#27 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012o.html#46 Random thoughts: Low power, High performance

--
virtualization experience starting Jan1968, online at home since Mar1970

NBC's website hacked with malware

Refed: **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: NBC's website hacked with malware
Newsgroups: alt.folklore.computers
Date: Fri, 08 Mar 2013 15:35:17 -0500
Rob Doyle <radioengr@gmail.com> writes:
Hopefully was deliberately altered information like the Concordsky...

re:
https://www.garlic.com/~lynn/2013b.html#68 NBC's website hacked with malware
https://www.garlic.com/~lynn/2013c.html#54 NBC's website hacked with malware

just saw a blog reference conjecturing (given the enormous troubles with f35) that possibly the reversed happened ...

What if China Not Just Hacked -- But Sabotaged -- the F-35?
http://www.emptywheel.net/2013/02/24/what-if-china-not-just-hacked-but-sabotaged-the-f-35/

other recent posts mentioning f35
https://www.garlic.com/~lynn/2013b.html#62 America Is Basically Helpless Against The Chinese Hackers
https://www.garlic.com/~lynn/2013c.html#45 A Matter of Mindset: Iraq, Sequestration and the U.S. Army

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Fri, 08 Mar 2013 17:53:32 -0500
Anne & Lynn Wheeler <lynn@garlic.com> writes:
and even more topic drift ... old post mentioning early Jan92 meeting in Ellison's conference room regarding FCS for 128-way cluster scale-up
https://www.garlic.com/~lynn/95.html#13
and related old email
https://www.garlic.com/~lynn/lhwemail.html#medusa


re:
https://www.garlic.com/~lynn/2013c.html#63 What Makes an Architecture Bizarre?

for even more trivia, one of the IBM engineers mentioned in the "End of IBM ACS Project"
https://people.computing.clemson.edu/~mark/acs_end.html
referenced
https://www.garlic.com/~lynn/2013c.html#46 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#47 What Makes an Architecture Bizarre?

goes on to become senior executive vp ... and sponsors some number of activities. He retires Oct91 and various of his sponsored efforts are audited (including supercomputer activity in kingston ... which was working on supercomputer design as well as providing funding to Steve Chen). A technology conference was then announced for mid-Jan92 as part of scouring the company for technology to be used for supercomputer.

one of the engineers working on FCS wants to give a presentation on medusa at the conference. we strongly advise against it because the conference was really trolling the company for technology (to appropriate). he doesn't believe us and goes ahead and gives the talk anyway. within couple weeks, the effort is then transferred to kingston, we are told we can't work on anything with more than four processors, and a couple weeks later announced as supercomputer.

we had been doing work for cluster-scale-up for both commercial as well as national lab, scientific, and numeric intensive. some past posts
https://www.garlic.com/~lynn/subtopic.html#hacmp

but the supercomputer announcement is for numeric intensive ONLY ... press from 17Feb1992:
https://www.garlic.com/~lynn/2001n.html#6000clusters1
and then to add insult to injury ... more press that cluster interest caught the company by surprise(?) press from 11May1992
https://www.garlic.com/~lynn/2001n.html#6000clusters2

for other drift, misc. past posts mentioning doing some consulting for Steve Chen when he was CTO at Sequent (before it was bought by IBM).
https://www.garlic.com/~lynn/2002h.html#42 Looking for Software/Documentation for an Opus 32032 Card
https://www.garlic.com/~lynn/2006y.html#38 Wanted: info on old Unisys boxen
https://www.garlic.com/~lynn/2007n.html#1 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2008d.html#63 was: 1975 movie "Three Days of the Condor" tech stuff
https://www.garlic.com/~lynn/2009.html#5 Is SUN going to become x86'ed ??
https://www.garlic.com/~lynn/2009e.html#7 IBM in Talks to Buy Sun
https://www.garlic.com/~lynn/2009o.html#29 Justice Department probing allegations of abuse by IBM in mainframe computer market
https://www.garlic.com/~lynn/2009p.html#58 MasPar compiler and simulator
https://www.garlic.com/~lynn/2009s.html#5 While watching Biography about Bill Gates on CNBC last Night
https://www.garlic.com/~lynn/2009s.html#42 Larrabee delayed: anyone know what's happening?
https://www.garlic.com/~lynn/2009s.html#59 Problem with XP scheduler?
https://www.garlic.com/~lynn/2010e.html#42 search engine history, was Happy DEC-10 Day
https://www.garlic.com/~lynn/2010e.html#68 Entry point for a Mainframe?
https://www.garlic.com/~lynn/2010e.html#70 Entry point for a Mainframe?
https://www.garlic.com/~lynn/2010f.html#48 Nonlinear systems and nonlocal supercomputing
https://www.garlic.com/~lynn/2010i.html#61 IBM to announce new MF's this year
https://www.garlic.com/~lynn/2010o.html#58 So why doesn't the mainstream IT press seem to get the IBM mainframe?
https://www.garlic.com/~lynn/2011c.html#24 If IBM Hadn't Bet the Company
https://www.garlic.com/~lynn/2011d.html#7 IBM Watson's Ancestors: A Look at Supercomputers of the Past
https://www.garlic.com/~lynn/2011f.html#85 SV: USS vs USS
https://www.garlic.com/~lynn/2011o.html#79 Why are organizations sticking with mainframes?
https://www.garlic.com/~lynn/2012p.html#13 AMC proposes 1980s computer TV series Halt & Catch Fire

--
virtualization experience starting Jan1968, online at home since Mar1970

How to Cut Megabanks Down to Size

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: How to Cut Megabanks Down to Size
Date: 9 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
"Confidence Men" characterizes the economic A-team instrumental in getting the president originally elected ... however in the "Japan or Sweden" economic policy choice, they were going to choose the "Sweden" solution and hold those responsible accountable; instead the President appoints the B-team, many of who participated in causing the economic mess, who choose the "Japan solution", and are not inclined to hold those responsible accountable
https://www.amazon.com/Confidence-Men-Washington-Education-ebook/dp/B0089LOKKS/
reference to the swedish solution
http://www.nytimes.com/2008/09/23/business/worldbusiness/23krona.html

Warren as TARP Overseer, in her congressional testimony about TARP severely criticized the use of TARP and those responsible for economic mess.
https://en.wikipedia.org/wiki/Elizabeth_Warren

she then worked on establishing much of the policies for the new consumer protection bureau ... and when it looked like she would be its first head, wallstreet lobbied hard to block that appointment.

Note however, every once and awhile the news will refer to Congress as Kabuki theater (especially the 1603-1629 period)
https://en.wikipedia.org/wiki/Kabuki

... what is happening publicly is mostly staged for show and obfuscation for what is going on behind the scenes; aka what goes on in any broadcast congressional hearings may not result in any change. Congressional Oct2008 hearings delved deep into the pivotal role that the rating agencies played in the economic mess (lots of testimony that rating agencies sold triple-A ratings on toxic CDOs when both the rating agencies and the sellers knew they weren't worth triple-A)

note as undergraduate, I was doing lots of computer stuff and being recruited by a new online service that was moving up the value stream into financial data. I didn't join them but maintained contact with them over the years. In the rating agencies congressional hearings, part of the testimony was that the rating agencies business model changed and became severely mis-aligned in the early 70s (ratings are for benefit of the buyers, but their interests were now aligned with the sellers); regulation is much more difficult when those regulated are incented to do the wrong thing. In the very early 70s (about the time, congressional testimony said the rating agency business model became mis-aligned), the company (that was recruiting me in the 60s) bought the "Pricing Services" division from major rating agency (possibly interpretation that rating agency no longer needed to price things they were rating). This company was briefly mentioned Jan2009 when there was still some facade that TARP might be used to buy toxic assets.
https://en.wikipedia.org/wiki/Troubled_Asset_Relief_Program

However, I've periodically mentioned that $700B wouldn't make a dent in toxic assets; at end of 2008, just the four largest too-big-to-fail were still holding $5.2T off-book.
Bank's Hidden Junk Menaces $1 Trillion Purge
http://www.bloomberg.com/apps/news?pid=newsarchive&sid=akv_p6LBNIdw&refer=home
and there was over $27T done during the bubble:
https://www.bloomberg.com/news/articles/2008-10-27/evil-wall-street-exports-boomed-with-fools-born-to-buy-debt

fall of 2008, there were several tens of billions of toxic assets sold for 22cents on the dollar. The TARP $700B wouldn't even have covered the four largest too-big-to-fail (at 22cents on the dollar); however at 22cents on the dollar, the too-big-to-fail losses would have been so large that they would be declared insolvent and forced to be liquidated.

also ... posted at the start of this discussion: disclaimer: Jan2009 I was asked to "HTMLize" the recently scanned (fall2008 at Boston Public Library) Pecora Hearings (congressional hearings into crash of 29 that resulted in Glass-Steagall) with heavy internal cross-links and lots of URLs between what happened then and what happened this time (some anticipation that the new congress would have appetite to do something). After working on it for some time, I got a call that it wouldn't be needed to after all (some reference to enormous pile of wallstreet money blanketing capital hill).

story is that sec. of treasury and others got TARP appropriations passed based on purchasing toxic assets ... but with provision that the secretary had discretion on how to use it. wallstreet possibly skimmed $4T-$5T in fees and commissions on the over $27T in transactions (significant contributor to claims that wallstreet tripled in size as percent of GDP during the bubble and bonuses went up more than 400%). However, it wasn't the only mechanism. They would also create toxic CDOs designed to fail, pay for triple-A ratings, sell them to their customers and then take out CDS gambling bets that they would fail ... lots of these bets with AIG. AIG was negotiating to pay off these bets at 50-60 cents on the dollar when the sec. of treasury (and former ceo of the firm with the largest amount of CDS bets with AIG) steps in, says that it is illegal for AIG to pay less than 100cents on the dollar, forces them to take fed. TARP funds (to pay off the CDS bets at 100cents on dollar) and makes them sign document that they can't sue any of the firms that had placed CDS gambling bets.

past posts in this thread:
https://www.garlic.com/~lynn/2013.html#44 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#51 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#57 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013.html#66 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#0 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#9 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#48 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#50 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#54 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#65 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013b.html#74 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#3 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#5 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#12 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#26 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#42 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#55 How to Cut Megabanks Down to Size
https://www.garlic.com/~lynn/2013c.html#61 How to Cut Megabanks Down to Size

--
virtualization experience starting Jan1968, online at home since Mar1970

relative speeds, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 09 Mar 2013 11:28:51 -0500
Robert Wessel <robertwessel2@yahoo.com> writes:
I/O is horribly slower in relation the CPU today than 50 years ago. 2314s were about 60ms access time and had a transfer rate of about 300KB/s (and if your workload was mainly random, the effective throughput was drastically less than that, and even worse for the overall channel, since these were selector channels, and the access times were hard to use for transferring data from other disks). Modern drives are a bit below 5ms, and can manage 100MB/S+ for long-ish sequential accesses. OTOH, the systems they're attached too have gotten 100,000 times faster.

In any event, caching is all well and good, but mainframe I/O lags other systems rather badly, the old channel protocol has considerable overhead, which explains that apparently excessive* number of channels you can attach to these systems. Not to mention the overhead of CKD emulation.

• Using the same Fiber Channel hardware, big POWER systems, for example, manage much more I/O per channel.


re:
https://www.garlic.com/~lynn/2013c.html#25 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#52 What Makes an Architecture Bizarre?

there are observations that memory latency (cache miss) measured in number of processor cycles, is comparable to 60s disk I/O latency when measured in number of processor cycles (of 360 computers).

as a result, there are attempts to get the equivalent of multi-tasking that allow overlapped execution while waiting ... hyperthreading and out-of-order execution ... give the execution unit something else to do while waiting for memory on cache miss.

hyperthreading is multiple i-streams (simulated multiprocessor) that have instructions feed from independent instruction streams ... when one i-stream stalls on cache miss ... possibility of executing something from independent i-stream. out-of-order execution ... is attempting to asyncrhonously execute something else from same i-stream during instruction stall on i-stream.

i've periodically mentioned having asked to help with effort to do dual i-stream for 370/195 (nearly 30yrs ago) ... 370/195 pipeline would stall on conditional branches as a result, codes had to be carefully crafted to keep 195 execution running at full speed (most codes only kept 195 execution only half busy because of conditional branch stalls). idea was to implement two i-streams (simulating two processor) ... dual PSWs, dual set of registers, etc ... but only the same execution units. hope that a pair of independent i-streams (each running at half-rate because of conditional branch stalls) would keep machine running at full rate (never was announced) implementation was very similar to red/blue proposed for acs:
https://people.computing.clemson.edu/~mark/acs_end.html

Sidebar: Multithreading

In summer 1968, Ed Sussenguth investigated making the ACS-360 into a multithreaded design by adding a second instruction counter and a second set of registers to the simulator. Instructions were tagged with an additional "red/blue" bit to designate the instruction stream and register set; and, as was expected, the utilization of the functional units increased since more independent instructions were available.


... snip ...

recent posts in this thread referring to enormous throughput degradation of FICON layer on top of fiber channel
https://www.garlic.com/~lynn/2013c.html#62 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#63 What Makes an Architecture Bizarre?

misc. past posts mentioning 370/195 dual i-stream
https://www.garlic.com/~lynn/94.html#38 IBM 370/195
https://www.garlic.com/~lynn/99.html#73 The Chronology
https://www.garlic.com/~lynn/99.html#97 Power4 = 2 cpu's on die?
https://www.garlic.com/~lynn/2000g.html#15 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001b.html#38 Why SMP at all anymore?
https://www.garlic.com/~lynn/2001c.html#1 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001j.html#27 Pentium 4 SMT "Hyperthreading"
https://www.garlic.com/~lynn/2001n.html#39 195 was: Computer Typesetting Was: Movies with source code
https://www.garlic.com/~lynn/2001n.html#62 The demise of compaq
https://www.garlic.com/~lynn/2001n.html#63 Hyper-Threading Technology - Intel information.
https://www.garlic.com/~lynn/2001n.html#86 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
https://www.garlic.com/~lynn/2002.html#52 Microcode?
https://www.garlic.com/~lynn/2002f.html#42 Blade architectures
https://www.garlic.com/~lynn/2002g.html#70 Pipelining in the past
https://www.garlic.com/~lynn/2002g.html#76 Pipelining in the past
https://www.garlic.com/~lynn/2002h.html#23 System/360 shortcuts
https://www.garlic.com/~lynn/2002k.html#16 s/w was: How will current AI/robot stories play when AIs are
https://www.garlic.com/~lynn/2002p.html#58 AMP vs SMP
https://www.garlic.com/~lynn/2003.html#14 vax6k.openecs.org rebirth
https://www.garlic.com/~lynn/2003f.html#33 PDP10 and RISC
https://www.garlic.com/~lynn/2003i.html#5 Name for this early transistor package?
https://www.garlic.com/~lynn/2003l.html#48 IBM Manuals from the 1940's and 1950's
https://www.garlic.com/~lynn/2003m.html#60 S/360 undocumented instructions?
https://www.garlic.com/~lynn/2003p.html#3 Hyperthreading vs. SMP
https://www.garlic.com/~lynn/2004.html#7 Dyadic
https://www.garlic.com/~lynn/2004.html#21 40th anniversary of IBM System/360 on 7 Apr 2004
https://www.garlic.com/~lynn/2004.html#27 dual processors: not just for breakfast anymore?
https://www.garlic.com/~lynn/2004e.html#1 A POX on you, Dennis Ritchie!!!
https://www.garlic.com/~lynn/2004o.html#18 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005.html#19 The Soul of Barb's New Machine (was Re: creat)
https://www.garlic.com/~lynn/2005f.html#4 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005f.html#22 System/360; Hardwired vs. Microcoded
https://www.garlic.com/~lynn/2005m.html#9 IBM's mini computers--lack thereof
https://www.garlic.com/~lynn/2005o.html#44 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2005p.html#1 Intel engineer discusses their dual-core design
https://www.garlic.com/~lynn/2005p.html#14 Multicores
https://www.garlic.com/~lynn/2006c.html#6 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006c.html#29 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#0 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006d.html#10 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006m.html#51 The System/360 Model 20 Wasn't As Bad As All That
https://www.garlic.com/~lynn/2006n.html#60 How Many 360/195s and 370/195s were shipped?
https://www.garlic.com/~lynn/2006r.html#2 Was FORTRAN buggy?
https://www.garlic.com/~lynn/2006s.html#21 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006t.html#41 The Future of CPUs: What's After Multi-Core?
https://www.garlic.com/~lynn/2007e.html#52 US Air computers delay psgrs
https://www.garlic.com/~lynn/2007f.html#10 Beyond multicore
https://www.garlic.com/~lynn/2007l.html#34 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007r.html#20 Abend S0C0
https://www.garlic.com/~lynn/2007t.html#37 Intel memory latencies
https://www.garlic.com/~lynn/2008c.html#92 CPU time differences for the same job
https://www.garlic.com/~lynn/2009d.html#54 mainframe performance
https://www.garlic.com/~lynn/2009e.html#5 registers vs cache
https://www.garlic.com/~lynn/2009k.html#49 A Complete History Of Mainframe Computing
https://www.garlic.com/~lynn/2009r.html#59 "Portable" data centers
https://www.garlic.com/~lynn/2009s.html#6 "Portable" data centers
https://www.garlic.com/~lynn/2010i.html#6 45 years of Mainframe
https://www.garlic.com/~lynn/2011c.html#26 If IBM Hadn't Bet the Company
https://www.garlic.com/~lynn/2012.html#60 Has anyone successfully migrated off mainframes?
https://www.garlic.com/~lynn/2012d.html#64 Layer 8: NASA unplugs last mainframe
https://www.garlic.com/~lynn/2012d.html#73 Execution Velocity
https://www.garlic.com/~lynn/2012d.html#74 Execution Velocity
https://www.garlic.com/~lynn/2012d.html#79 NASA unplugs their last mainframe
https://www.garlic.com/~lynn/2012e.html#96 Indirect Bit
https://www.garlic.com/~lynn/2012l.html#29 X86 server
https://www.garlic.com/~lynn/2012l.html#56 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012n.html#32 390 vector instruction set reuse, was 8-bit bytes
https://www.garlic.com/~lynn/2012n.html#33 390 vector instruction set reuse, was 8-bit bytes

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 09 Mar 2013 14:34:18 -0500
hancock4 writes:
You mentioned numerous improvements to the central processing unit (eg multiple cores). But what about all the improvements--beyond plain speed--made to disk access, such as compression, indexing, etc.? I'm pretty sure a modern mainframe disk can do many things beyond merely faster access and transfer time.

re:
https://www.garlic.com/~lynn/2013c.html#25 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#52 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#67 What Makes an Architecture Bizarre?

big issue with FCS was that end-to-end latency got to be significant throughput issue ... especially with the traditional mainframe half-duplex channel paradigm with enormous amount of end-to-end handshaking for every operation.

FCS was serial designed to be dual-simplex .. concurrent tranfer in both directions ... but to further increase throughput ... download complex request to the opposite end to minimize end-to-end handshaking.

As I mentioned, I did this with HYPERchannel channel extender in 1980 ... and was significant factor in masking part of the transmission path was T1 (mbit/sec not mbyte/sec).

Simply mapping mainframe channel protocol on top of FCS really cut FCS throughput potential because of the enormous amount of back&forth for transfers ... partially fixed recently with introduction of TCWs (which is similar to what I had done for HYPERchannel in 1980). ... as referenced peak z196 i/o benchmark achieve 2M IOPS with 104 FICON channels (each one layered on FCS) ... compared to recently announced single FCS for e5-2600 claimed to be capable of over 1M IOPS (two such FCS capable of more throughput than 104 mainframe FICON channels ... where 104 mainframe FICON channels actually have 104 FCS underneath).

The other issue is mainframe maintains requirement for CKD disk operation ... even though no real CKD disks have been manufactured for decades ... they are all simulated on standard industry fixed-block disks (also cutting into throughput because of the simulation overhead).

In late 70s, mainframe disks introduced FBA ... concurrent with traditional CKD disks. DOS/VS, VS1 and VM370 all provided support for FBA disks ... but not MVS ... continuing to require CKD disks until this day. I've periodically mentioned that I was told that I needed a $26M business case for MVS FBA ... even if I provided them completely developed and tested FBA support ... to cover costs of documentation, training, and education. Futhermore I could only use incremental new sales (aka needed $200M-$300M additional sales) ... and couldn't use justification of life-cycle savings ... and since they were already selling all the disks they could make, any FBA support would just change the equivalent amount of CKD to FBA with no new, incremental sales.

misc. past posts mentioning mainframe CKD, FBA, and multi-track search
https://www.garlic.com/~lynn/submain.html#dasd

the lack of FBA support also had impact on MVS moving into the exploding (4341) mid-range market ... since the only new mid-range disk (that was easily deployed out into non-traditional datacenter areas) was 3370 FBA ... this is besides the high skill & people costs associated with support an MVS installation ... recent reference
https://www.garlic.com/~lynn/2013c.html#53 What Makes an Architecture Bizarre?

to partially compensate, they eventually came out with 3375 ... which was 3370 with CKD emulation.

note that enhanced SCSI ... with cheaper version of high-performance than FCS ... is moving up the value chain ... recent news item:

CEBIT: Adaptec demos 12Gbps Serial Attached SCSI
http://news.techworld.com/data-centre/3433947/adaptec-demos-12gbps-serial-attached-scsi/

from above:
"We are showing a sequential read performance of roughly 760 megabytes per second. That is obviously faster than what you would get with the 6Gbps interface, which enables you to do 550 megabytes per second," Frick said.

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sat, 09 Mar 2013 18:46:39 -0500
John Levine <johnl@iecc.com> writes:
Back in the 1970s I wrote Unix disk drivers that did seek separation and request sorting to sort of do that at the driver level, which was a considerable improvement over the earlier FIFO, but it's hopeless in the computer these days since the geometry of the disks is typically too complex for the computer to discover.

re:
https://www.garlic.com/~lynn/2013c.html#25 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#52 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#67 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#68 relative mainframe speeds, was What Makes an Architecture Bizarre?

I did similar rewrite for cp67 as undergraduate in the 60s. cp67 had been fifo, single request at a time, both for 2314 and 2301 fixed-head drum.

2314 then was both avg. arm seek and avg. rotational delay for every request. 2301 was avg. rotational delay on every request (had head for every track).

cp67 2301 format had 9 4k pages across pair of tracks (5th page spanned the end of one track and start of next). single fifo request queuing peaked/saturated at around 80page tranfers/sec. with chained request ordering could peak nearly 270page tranfers/sec.

2314 with fifo single request queuing
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2314.html

2314 2400/rpm, 13mills avg. rotation delay, avg arm access of 60millis, or about 14pgs/sec ... ordered arm seek queueing and chained requests could double that to 26pgs/sec.

as referenced upthread ... this comparison (originally from early 80s)
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door

cambridge had a 768kbyte memory 360/67 with three 2301 drums and 45 2314 disk drives (five 8+1 strings and one five drive string; CE painted different strings different colors to aid operators in locating specific drive for mount/unmount requests.

early 80s, there was (two processor) 3081 (maybe 40-50 times increase in processing power), 32mbytes of memory (60-70 times amount of memory for application use), but number of users only increased by factor of four times ... and number of physical disk i/os had only increased by factor of three times (slightly more transferred per physical disk i/o). configuration had gone from 45 2314 disks to 32 3380 disks ... but avg. access only increase by approx. four times (but number of arms decreased ... so number of operations/sec was less than four times increase).

as previously mentioned, based on processing power and amount of real storage, the number of users should have increased from 80users to 4000users ... but the number typically only increased by factor of four to 320users.

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 10 Mar 2013 11:44:40 -0400
Stephen Fuld <SFuld@alumni.cmu.edu.invalid> writes:
Where did the idea of everyone calling the 2301 and its successors "drums" come from? They clearly are physically not drums, but fixed head disks. Coming to those devices from systems that had actual drums for high speed storage, it always struck me as both odd and incorrect.

re:
https://www.garlic.com/~lynn/2013c.html#69 relative mainframe speeds, was What Makes an Architecture Bizarre?

2301 & its 2303 cousin, are drums:
http://www.columbia.edu/cu/computinghistory/drum.html

2303 read/write single head at a time. 2301 read/write four heads in parallel, four times the data transfer, 1/4th the number of tracks, each track four times larger.

follow-on 2305 was fixed-head disk with platters
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_2305.html

there were two models of 2305 ... standard 1.5mbyte/sec transfer. another with same number of heads, but half the capacity, twice the data transfer (requiring special two-byte channel interface) and half the capacity. the 3mbyte/sec transfer 2305 had pairs of heads on each track (transferring in parallel) off-set 180degrees ... as a result, avg. rotational delay was quarter revolution (not half revolution).

past posts mentioning 2301 &/or 2305 with image references
https://www.garlic.com/~lynn/2003b.html#10 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2007e.html#64 FBA rant
https://www.garlic.com/~lynn/2007k.html#38 John W. Backus, 82, Fortran developer, dies
https://www.garlic.com/~lynn/2007l.html#49 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2008q.html#43 TOPS-10
https://www.garlic.com/~lynn/2010m.html#10 History of Hard-coded Offsets
https://www.garlic.com/~lynn/2012e.html#103 Hard Disk Drive Construction

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 10 Mar 2013 12:14:07 -0400
Robert Wessel <robertwessel2@yahoo.com> writes:
Not really. Load time dynamic linking could just do fix ups as always, run time dynamic linking would use pointers (and ultimately a call via a register), as always.

when I did page mapped filesystem, originally for cp67/cms ... some past posts
https://www.garlic.com/~lynn/submain.html#mmap

one of the hardest problems I had was with os/360 convention of relocatable adcons ... some past posts
https://www.garlic.com/~lynn/submain.html#adcon

lots of cms programs and applications were written for standard os/360 compilers ... and then use os/360 simulation to execute. output of standard os/360 compilers had what they called "relocatable address constants" (aka address pointers) ... which had default value ... but required that they were swizzled after being loaded (to value corresponding to where they had actually were loaded) ... but before being executed.

objective of page mapped filesystem was to do the page map .... w/o otherwise having to touch the executable image. the other objective was multiple different virtual address spaces could page map the same disk image executable and shared r/o image ... and at (concurrent) different virtual addresses. requirement for swizzling relocatable address constants (before execution for specific mapped image of execuitable) precluded most of those objectives.

tss/360 had different convention where "relocatble address constants" weren't part of the executable image ... so multiple different address spaces could share the same image (at different virtual addresses) and the address specific information was maintained in separate area.

however as undergraduate ... there was IBM SE that was still committed to tss/360 and he and I would vie for dedicated weekend time for the 360/67 ... he wanted it for work with tss/360 and I wanted it for work on os/360 as well as cp67/cms. I observed lots of severe performance issue with the tss/360 implementation of page-mapped filesystem ... which I would avoid later when doing the page-mapped filesystem for cp67/cms. We also did a joint fortran edit, compile & execute benchmark with simulated/synthetic users ... my benchmark on cp67/cms with 35 simulated users had better performance, response and throughput than his tss/360 benchmark (on identical hardware) with just four users.

during the Future System period part of the effort was to duplicate the page mapped filesystem (somewhat from tss/360 ... even though it was totally different machine architecture). this was part of my motivation for periodically ridiculing their efforts ... believing what I already had running on cp67/cms was significantly better than what they were writing (emperor new clothes) bluesky specifications. I also believed what I had already running for scheduling, dispatching, i/o ... nearly everything ... was better than lots of other specifications. some past Future System posts
https://www.garlic.com/~lynn/submain.html#futuresys

I would migrate from cp67/cms to vm370/cms during the period, some old email refs:
https://www.garlic.com/~lynn/2006v.html#email731212
https://www.garlic.com/~lynn/2006w.html#email750102
https://www.garlic.com/~lynn/2006w.html#email750430

one of my hobbies with science center cp67/cms was making production operating systems available for internal datacenters. as more and more internal datacenters moved from cp67/cms to vm370/cms, my distribution list declined significantly. The number of internal datacenters really picked back up after I migrated to vm370 and started csc/vm distribution.

During the Future System period much of the 370 activity was suspended and/or resources moved over to FS (including at the vm370/cms development group). Then after the failure of FS, there was mad rush to get stuff back into 370 product pipelines ... which contributed to decisions to pick up various pieces of things I had continued to do all during the FS period ... some went out in vm370 release 3 and VM370 release 4. Other stuff I was asked to package as independent kernel component as my "resource manager" (although 90% of the code wasn't strictly speaking resource manager and/or performance). some past posts
https://www.garlic.com/~lynn/subtopic.html#fairshare

however, i couldn't convince them to ship the page-mapped filesystem stuff (possible page-mapped filesystem stuff had been tainted by relationship with future system) ... and only very small subset of my memory sharing stuff (remapped so it didn't depend on page-mapped filesystem)

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 10 Mar 2013 12:18:54 -0400
Stephen Sprunk <stephen@sprunk.org> writes:
AMD and Intel design for both markets, and so did IBM, for a while. IBM eventually gave up when it became clear to Apple that a superior architecture (i.e. PowerPC) couldn't beat the raw thrust that Intel and AMD were able to apply to their pig (i.e. x86).

recent news item:

IBM moves Power Systems manufacturing from Minnesota to Mexico; A return to Guadalajara, where the weather and supply chain are better
http://www.theregister.co.uk/2013/03/08/ibm_power_systems_manufacturing_mexico/

from above:
The fact that only a few hundred people are making Power-based machines to serve all of the Americas region shows you just how far shipments have fallen over the past two decades. (KTTC, the local Rochester NBC affiliate, reported that workers at the plant said 200 full-timers and 150 part-timers would be laid off.)

... snip ...

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 10 Mar 2013 12:32:29 -0400
Stephen Fuld <SFuld@alumni.cmu.edu.invalid> writes:
But the text (and the picture) at that link say it is really a fixed head disk! I am talking about the discrepancy between what they were commonly called and their actual physical instantiation. i.e. they are not drums, which would be a cylindrical structure with magnetic coating on the outside, as opposed to a disk with its magnetic coating on the top and bottom.

re:
https://www.garlic.com/~lynn/2013c.html#69 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#70 relative mainframe speeds, was What Makes an Architecture Bizarre?

this mentions "fixed-head disk" in the subtext possibly because that is what most people are familiar with
http://www.columbia.edu/cu/computinghistory/drum.html

but the picture is cylinder with all the heads around the surface of the cylinder/drum

this is closer picture of the 2301 drum/cylinder (from wayback machine) those are the heads on the surface of the drum ... not the connections for enormous number of disk arms
https://web.archive.org/web/20060620002221/www.cs.ncl.ac.uk/events/anniversaries/40th/images/ibm360_672/slide12.jpg
picture of 2303
http://www.beagle-ears.com/lars/engineer/comphist/c20-1684/fig043.jpg

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Sun, 10 Mar 2013 17:04:17 -0400
John Levine <johnl@iecc.com> writes:
Full track reads were common, not sure if it could switch tracks and keep going for multitrack reads. Lynn might know. The 360/91 at Princeton had two strings of 8 2314s, so one disk from each string could be transferring at a time. These were selector rather than block multiplexor channels so I don't know how much seek separation they did.

re:
https://www.garlic.com/~lynn/2013c.html#68 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#69 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#70 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#73 relative mainframe speeds, was What Makes an Architecture Bizarre?

so a string could be on its own dedicated channel or on shared channel with other strings ... i.e. in theory up to 256 addresses per channel (or 36 strings).

(shared) channel, (shared string) controller, and device could all be busy during operation ... "locking" out any concurrent activity.

typical dasd channel program was seek, search record, tic (back to search, if didn't match) followed by read/write. typical operational did "stand-alone" seek ... which would disconnect from the channel & controller after initiation and then queue interrupt when in position. this allowed other operations to go on concurrently on the same channel. the stand-alone seek was completed (disk arm at correct cylinder), the seek was rechained and the full channel program executed (during which channel, controller, and device were busy, dedicated to the operation, only perviously initiated stand-alone seeks might be in progress).

the search operation would refetch the search argument from mainframe processor storage every time it encountered a new record and check for a match ... if it didn't match the next ccw would be executed ... typically a "TIC" (aka branch) back to the same search to repeat the operation. If the search criteria was successful, it then "branched" +16 (over the immediately following CCW) ... typically to the read/write operation. This resulted in (share) channel & (shared) controller being dedicated busy during average rotational delay (in addition to device). controller typically had additional administrative/overhead channel busy associated with starting/ending each CCW processing ... and each full channel program.

CMS could attempt to read/write multiple records on a track ... supporting filesystem requests up to 64kbytes ... and the associated records on disk were sequential contiguous. Problem is that both CMS & CP67 pretty much did scatter record allocation ... so there was nothing guaranteeing sequential contiguous allocation. max. 2314 track capacity was 7294bytes .... from my gcard dasd capacity formulae
https://www.garlic.com/~lynn/gcard.html#26.3

os/360 did much better job with contiguous allocation ... and access method parameters would allow for large record blocking, multiple block read, and multiple buffer read-ahead ... transparent to the application.

however, os/360 also made extensive use of multi-track search for directories (vtoc, pds directories, etc). recent post about large national retailer with large number of stores and applications provided by large multiple system (370/168) shared DASD/3330 datacenter ... where all systems shared single application program library on single 3330. The retail operation for the whole country was limited to loading two applications/sec (because PDS directory program library multi-track search operation took nearly 1/2sec ... during which time the associated channel & controller were also busy):
https://www.garlic.com/~lynn/2013.html#24 Is Microsoft becoming folklore?
https://www.garlic.com/~lynn/2013.html#25 Is Microsoft becoming folklore?
https://www.garlic.com/~lynn/2013.html#40 Searching for storage (DASD) alternatives
https://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?

however, cp67 and cms ... and other types of os/360 ... just used ckd DASD as logical FBA ... where records formated on disk were at fixed known positions and search identifer was simplistic sequential record number ... and there was some amount of effectively random access.

block multiplexor channels and "set sector" CCW were introduced for this mode of operation. 2305 and 3330 had additional track that had rotational position information which was constantly monitored for current rotational position information. software established the rotational position of each record ... a "set sector" CCW was added to channel program between the "seek" CCW and the "search" where the known rotational sector position of the desired record was specified. The "set sector" CCW would dynamically disconnect from channel&controller and then attempt to reconnect ... this attempted to eliminate the channel/controller busy during average rotational delay (somewhat analogous to channel/controller busy being eliminated during arm seek operation with "stand-alone" seeks). The downside was that if the channel reconnect failed, aka RPS-miss (because of busy with some other request), then the device would have to take another complete revolution before trying again.

2305 also introduced "multiple-exposures" .... basically eight unique device addresses for queuing channel programs to the same device. For 2301, I had done long multi-page channel program transfers ... possibly 10-20 in single request ... which would then have just a single average rotational delay for the start ... but all the page transfers carefully ordered to maximize transfers per rotation. This wasn't very effective at moderate paging levels since queue depth wasn't very deep. 2305 was formated with three 4k page records per track. It was possible to initiate single page request on any of the either available addresses ... where the use of the "set sector" only had channel/controller/device busy for just the single page transfer. However, with controller managing the multiple requests for the same device and the "set sector" ordering ... it would be possible to get three 4k page transfers per revolution ... even when only doing channel programs with single page request.

However, for 2314 & 3330 disk I did ordered seek queuing for both paging requests and cms filesystem requests. For paging requests, i broke them into individual 4k requests and all requests for records at the same arm position were ordered attempting to maximize the number of pages transferred per revolution. However, for cms filesystem, the virtual machine CCWs were just done with standard processing.

for my cms paged-mapped filesystem ... i did some extra stuff for contiguous allocation, asynchronous read-ahead (using page available flag for serialization, and other performance enhancements). on the cp67 (and/or vm370) kernel side the requests would flow into standard page i/o processing ... even combining page file requests from different cms into common transfer ... reordered to maximize transfer per revoluation. it also lifted the cms restriction that multi-record transfers had to be sequential contiguous .... multiple record transfers could be handled by the page-mapped stuff with standard page i/o processing (even if they weren't sequential contiguous). it was possible to do up to 19 track transfer (full 3330 cylinder) in single i/o operation.

now, in the 2301 and 3330 long page request chain ... where there might be several revolutions ... the normal terminal interrupt could be delayed even though quiet a few pages were already available for use (2305 single request i/o per exposure got around problem). So I added the feature of a PCI flag to CCW (programmed controlled interrupt) periodically in a long channel program. It was then possible to recongize some number of pages had already been transferred and were availalble ... even when the full I/O operation had completed.

separate multi-track issue. 3330s formated three 4k pages per track (13165 bytes). there was an issue with doing a track head switch and being able to do the tic/seek-track/set-sector/search/tic/read chained CCW channel program sequence between the end of the previous page record and the start of the next page record on a different track (other than at start of track, after the 1st page on a track and the 2nd page on a different track ... or 2nd page and 3rd page on different track). In order to increase the rotational latency time between end of one page and the start of the next page ... short "dummy" records were added to track format ... remember channel architecture precluded prefetch ... so this all had to happen serially while the device was rotating ... upthread mention about no prefetch:
https://www.garlic.com/~lynn/2013c.html#48 What Makes an Architecture Bizarre?

problem was that there was limited room on 3330 track for three 4k page records and dummy records ... and some models of 370 channel processing were so slow that they couldn't get through the channel program sequence in the time window provided by the limited dummy record size (track switching only possibly by skipping a page record transfer in rotation).

After transferring to san jose research in '77 (bldg 28), they also suckered me into playing disk engineer over in bldg 14&15 (across the street). ... some past posts getting to play disk engineer
https://www.garlic.com/~lynn/subtopic.html#disk

I tried to get multiple exposure added to 3350 (similar to 2305 multiple exposure) ... to improved queuing on moveable arm device (especially for 3350s with fixed-head feature). At its simplest I could overlap transfer from the 3350 fixed-head area overlapped with the moveable arm was moving/rotating. I got shot down my POK because they thought it might compete with electronic paging device that they were trying to justify. misc. past posts mentioning POK vulcan ... which never made it to announcement ... but they still shot down my multi-exposure for 3350s.
https://www.garlic.com/~lynn/99.html#8 IBM S/360
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/2000d.html#53 IBM 650 (was: Re: IBM--old computer manuals)
https://www.garlic.com/~lynn/2001n.html#65 Holy Satanism! Re: Hyper-Threading Technology - Intel information.
https://www.garlic.com/~lynn/2004d.html#73 DASD Architecture of the future
https://www.garlic.com/~lynn/2004e.html#3 Expanded Storage
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006s.html#45 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2006s.html#59 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2009k.html#61 Z/VM support for FBA devices was Re: z/OS support of HMC's 3270 emulation?
https://www.garlic.com/~lynn/2012i.html#47 IBM, Lawrence Livermore aim to meld supercomputing, industries

--
virtualization experience starting Jan1968, online at home since Mar1970

Still not convinced about the superiority of mainframe security vs distributed?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Still not convinced about the superiority of mainframe security vs distributed?
Date: 10 Mar 2013
Blog: Enterprise Systems
re:
http://lnkd.in/hDdvMA

note that the technical basis for the modern internet is tcp/ip, the operational basis for the modern internet was the NSFNET backbone, and the business basis for the modern internet was CIX.

we were working with NSF on what was suppose to become the NSFNET backbone ... some old email
https://www.garlic.com/~lynn/lhwemail.html#nsfnet

it originally was suppose to internconnect the NSF supercomputing centers and we were to get $20M to do the implementation. Congress then cut the budget and some other things happened and finally a RFP was released for the implementation. Internal politics stepped in (the communication group was strongly fighting client/server, distributed computing, etc; trying to preserve their terminal emulation paradigm) and we were prevented from responding to the RFP. The director of NSF tried to help by writing the company a letter 3Apr1986, NSF Director to IBM Chief Scientist and IBM Senior VP and director of Research, copying IBM CEO), but that just aggravating the internal politics (as were claims that what we already had running internally was at least five yrs ahead of all RFP responses).

At the time, the communication group was also internally generating an enormous amount of misinformation ... part of it was trying to justify the conversion of the internal network to SNA/VTAM (the internal network had been larger than arpanet/internet from just about the beginning until sometime late '85 or early '86 ... and was not based on SNA/VTAM) ... as well as making claims that SNA/VTAM could be used for the NSFNET backbone. somebody in the communication group had been collecting lots of the distributed misinformation and forwarded a copy (sort of analogous to small-time wikileaks or pentagon papers) ... small part reproduced here:
https://www.garlic.com/~lynn/2006w.html#email870109

The original mainframe tcp/ip support was done in vs/pascal ... and had none of the vulnerabilities that are epidemic in C-language based implementation ... however it had some performance issues. I then did the changes for RFC1044 support and in some tests at Cray Research got channel throughput using only modest amount of 4341 processor (possibly 500 times improvement in bytes moved per instruction executed). misc. past posts mentioning rfc 1044 support for mainframe tcp/ip https://www.garlic.com/~lynn/subnetwork.html#1044

For similar issue compared to c-language implementations, this is IBM Research review of security evaluation of Multics (implemented in PLI) ... which also didn't have any of the exploits and vulnerabilities that have been epidemic in C-language based implementations (aka while it is still possible to shoot yourself in the foot in other languages ... it is frequently nearly impossible not to shoot yourself in the foot in C)
http://www.acsac.org/2002/papers/classic-multics.pdf
original air force multics security evaluation
http://csrc.nist.gov/publications/history/karg74.pdf

large amount of pontificating about problems in C-language
https://www.garlic.com/~lynn/subintegrity.html#overflow

after another similar episode or two by some of the same executives involved in preventing us from doing NSFNET backbone, we decide to leave. It turns out that two of the people we had worked with on RDBMS cluster scale-up at Oracle ... mentioned in this old post about early Jan1992 meeting in Ellison's conference room
https://www.garlic.com/~lynn/95.html#13

are now at a small client/server startup and we are brought in to consult because they want to do payment transactions on their server, the startup had also invented this technology called "SSL"; the result is now frequently referred to as "electronic commerce". Part of "electronic commerce" was mapping "SSL" to payment business process, doing audits of SSL as well as businesses selling SSL digital certificates, and drawing up some policies for SSL deployment and operation. Some number of those policies were almost immediately violated ... resulting in some number of the exploits and vulnerabilities that continue to this day.

This is post
https://www.garlic.com/~lynn/2004e.html#43
with some of the work I was trying to do to profile/characterize all the exploits in the Mitre/NIST exploit database
http://cve.mitre.org/

I talked to Mitre about trying to make the (free-form) exploit descriptions a little more formal ... as part of trying to characterize frequency of different kinds of exploits ... but at the time they said they were lucky to get any description at all ... and trying to impose reporting standards might result in even less descriptive information.

in this particular analysis I did simple word and word-pair frequency counts

as an aside, in the early to mid 80s, a big part of the internal network (again larger than arpanet/internet from just about the beginning and non-VTAM/non-SNA) was the exploding number of distributed vm/4341s ... going into internal departmental supply rooms and/or converted conference rooms ... I've frequently commented that this was the leading edge of the distributed computing tsunami that was hitting. past posts mentioning internal network
https://www.garlic.com/~lynn/subnetwork.html#internalnet

late 80s, a senior disk engineer got a talk scheduled in the annual, internal, world-wide communication group conference and opened the talk with the statement that the communication group was going to be responsible for the demise of the disk division. The issue was the disk division was seeing drop in disk sales as data was fleeing the datacenter to more distributed computing friendly platforms. They had come up with a number of solutions to rectify the situations ... but they were constantly vetoed by the communication group that had strategic ownership of everything that crosses the datacenter walls and were strongly fighting off client/server and distributed computing ... trying to preserve their terminal emulation install base
https://www.garlic.com/~lynn/subnetwork.html#emulation

there has been recent thread in ibm-main mailing list about page protect ... a couple of really long-winded posts in that thread:
https://www.garlic.com/~lynn/2013c.html#31 REFRPROT History Question
https://www.garlic.com/~lynn/2013c.html#32 REFRPROT Hisotry Question

the above includes this old email about failed attempt to get page protect added to 370/168
https://www.garlic.com/~lynn/2013c.html#email800227

this is after segment protect ... which had been in the original 370 virtual memory architecture, had been dropped ... because of schedule slippage in retrofitting virtual memory hardware to 370/165. One of the issues was that with segment protect ... it was trivial to have some address spaces with shared segment having r/w access and other address spaces sharing the same segment only have r/o access to the same shared segment. This was used (DWSS) in the original relational/sql DBMS implementation ... done on vm370/145 at San Jose Research. It was sort of got out under the radar as SQL/DS because POK favorite son batch operating system was pre-occupied with EAGLE. When EAGLE floundered, there was a request about how fast could a port be done to MVS (which was eventually released as DB2).

--
virtualization experience starting Jan1968, online at home since Mar1970

relative speeds, was What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 11 Mar 2013 09:29:06 -0400
Stephen Sprunk <stephen@sprunk.org> writes:
"Online banking" is a negligible risk, whereas it is almost certain that your information will get compromised by some vendor (even of the brick and mortar kind) getting hacked or just plain being stupid.

Remember, if something is on the news, that means it's rare enough that you shouldn't worry about it. It's the things that _don't_ make the news, due to being so common, that you should worry about.


we had been doing cluster scale-up for both commercial and scientific, numerical intensive ... recent reference
https://www.garlic.com/~lynn/2013c.html#63 What Makes an Architecture Bizarre?
also
https://www.garlic.com/~lynn/2013c.html#75 Still not convinced about the superiority of mainframe security vs distributed?

commercial cluster scale-up reference in this old post about early jan92 meeting in ellison's conference room
https://www.garlic.com/~lynn/95.html#13

later after cluster scale-up is tranferred and we are told we can't work on anything with more than four processors, we decide to leave. Two of the other people mentioned in the Ellison meeting also move on and show up at a small client/server startup. We are brought in as consultants because they want to do payment transactions on their server, the startup had also invented this technology called "SSL" they want to use; the result is now frequently called "electronic commerce".

we are then involved in numerous things related to financial industry. later in the 95/96 time-frame, there were financial conferences where the dialup consumer online bank operations give presentations on why they are moving to the internet (basically eliminate their proprietary dialup online banking infrastructure and the significant associated customer support costs for supporting proprietary dialup online infrastructure).

at the same time, the dailup online commercial cash management/banking infrastructures claim that they will *NEVER* move to the internet because of a long list of security issues (many of which still result in exploits and vulnerabilities to this day). Note for whatever reason, those commercial dialup online cash management/banking operations have also moved to the internet. One of the issues since then has been commercial banking users in legal action with their financial institutions after exploit ... in part because commercial entities aren't subject to the same legal protections as consumers. misc. recent posts
https://www.garlic.com/~lynn/2012b.html#52 Banking malware a growing threat, as new variant of Zeus is detected
https://www.garlic.com/~lynn/2012b.html#71 Password shortcomings
https://www.garlic.com/~lynn/2012e.html#24 ExplicitTacit
https://www.garlic.com/~lynn/2012i.html#18 Zeus/SpyEye 'Automatic Transfer' Module Masks Online Banking Theft
https://www.garlic.com/~lynn/2012i.html#79 Does Two-Factor Authentication Need Fixing?
https://www.garlic.com/~lynn/2012j.html#0 Federal appeal court raps bank over shoddy online security
https://www.garlic.com/~lynn/2012j.html#18 Monopoly/ Cartons of Punch Cards
https://www.garlic.com/~lynn/2012j.html#57 Yahoo Password Breach: 7 Lessons Learned - Security - Attacks/breaches - Informationweek
https://www.garlic.com/~lynn/2012j.html#59 Bank Sues Customer Over ACH/Wire Fraud
https://www.garlic.com/~lynn/2012j.html#68 The Myth of Password Complexity & Frequent Change Rules
https://www.garlic.com/~lynn/2012j.html#73 Is it time to consider a stand-alone PC for online banking?
https://www.garlic.com/~lynn/2012j.html#94 Gordon Crovitz: Who Really Invented the Internet?
https://www.garlic.com/~lynn/2012l.html#32 Use another browser - Kaspersky follows suit
https://www.garlic.com/~lynn/2012p.html#49 Regulator Tells Banks to Share Cyber Attack Information
https://www.garlic.com/~lynn/2013c.html#2 Legal Lessons from PATCO Fraud Case

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 11 Mar 2013 09:58:35 -0400
Robert Wessel <robertwessel2@yahoo.com> writes:
The larger and faster 3330 disk shipped in about 1973. But assuming we're talking about before that, and assuming we're talking about early 370s or 360s, you were limited to no more than five selector or block multiplexor channels, each of which would address no more than 256 devices. Later models allowed 16* channels, and then channel set switching allowed several sets of 16 channels, and then XA made it 256 channels, and now we can have multiple groups of 256 channels!

re:
https://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?

minor issue, 3330-II was twice the capacity ... i.e. twice as many cylinders (808 cyls rather than 404 cyls). in my old tome about disks relative system throughput decreasing (disks got less faster than the rest of the system) ... one of the calculations was nominal avg. no. accesses per second prorated by amount of data under an arm ... aka avg. no. accesses per second per mbyte.
https://www.garlic.com/~lynn/93.html#21 Too much data on an actuator (was: 3.5 inch *9GB* )
https://www.garlic.com/~lynn/93.html#31 Big I/O or Kicking the Mainframe out the Door
https://www.garlic.com/~lynn/95.html#8 3330 Disk Drives
https://www.garlic.com/~lynn/99.html#6 3330 Disk Drives
https://www.garlic.com/~lynn/2003b.html#67 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#68 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#69 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2003b.html#70 Disk drives as commodities. Was Re: Yamhill
https://www.garlic.com/~lynn/2006.html#38 Is VIO mandatory?
https://www.garlic.com/~lynn/2006l.html#10 virtual memory
https://www.garlic.com/~lynn/2008e.html#60 z10 presentation on 26 Feb
https://www.garlic.com/~lynn/2008k.html#75 Disk drive improvements
https://www.garlic.com/~lynn/2009l.html#66 ACP, One of the Oldest Open Source Apps

as mentioned here current ("FICON") channels are an extremely heavyweight protocol that rides on top of fiber-channel standard that enormously cuts the native FCS throughput
https://www.garlic.com/~lynn/2013c.html#62 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#63 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#67 relative speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#68 relative mainframe speeds, was What Makes an Architecture Bizarre?

internally ... one of the things we looked at in the transition from 3350 to 3380 ... if you replaced 3350s with 3380 having the same amount of disk space ... there were fewer arms and worse throughput. to have the same amount of throughput as 3350s, 3380s had to be configured at 80% of capacity.

at share user group meeting there was semi-facetious resolution asking IBM for a "fast" 3380. It was a controller microcode load that only allowed access to half the number of cylinders ... avg. access goes up because only half the distance to travel. the suggestion was that ibm could charge extra for the "fast" 3380 ... it was countermeasure to datacenter administrators who saw it as false economy to not load a disk to full capacity (this would be an ibm model that was limited to half the capacity and would let datacenter adminstrator feel better by charging them more money for the feature).

normal 360 two/multi-processor had shared memory but required independent i/o channels. symmetric i/o operations were simulated by configuring the two sets of independent channels with similar addresses connected to "twin-tailed" controllers.

hover, while simplex 360/67 was essentially 360/65 with added relocatable address hardware ... 360/67 multiprocessor (originally designed to support 4-way ... but mostly 2-way were built except for possibly one or two 3-ways) ... was a different beast. It had channel controller allowing all processors to address all channels (something not seen again to 3081/XA).

I've mentioned pereiodically that after failure of FS
https://www.garlic.com/~lynn/submain.html#futuresys

there was mad rush to get (hardware & software) products back into 370 pipeline ... basically 303x effort was kicked off in parallel with 3081/xa efforts.

for 303x i/o, they took the integrated channel microcode from the 158 and made it into a channel director (six channels). a 3031 was a 370/158 engine with only the 370 microcode and a second 370/158 engine ("channel director") with only the integrated channel microcode (and no 370 microcode). A 2-way 3031 multiprocessor was actually four 370/158 engines (two 370 processor engines, each having its own channel director).

a 3032 was 370/168-3 configured to work with channel director.

a 3033 started out 168 logic mapped to 20% faster chips (chips also had 10 times the number of circuits by 90% initially went unused). Some late optimization of logic got 3033 (using more circuits/chip) up to 1.5times 168. 3033 could have three channel directors (theoretically 18 channels, but only 16 could be used).

of the 148, 4341, 158, 168, etc ... the 158 channels were the slowest of the bunch ... this shows up in some extensive tests that I had done regarding how fast different processor channels could do 3330 head switch
https://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What Makes an Architecture Bizarre?

158 was absolutely the slowest and the worst of the bunch ... which is repeated for all models of 303x using 158 integrated channel microcode for their channel directors.

for other drift old post discussing cutting inter-track gap on 3380 for double & triple density models (original 3380, the inter-track gap was 20 track widths):
https://www.garlic.com/~lynn/2006s.html#30 Why magnetic drums was/are worse than disks ?
https://www.garlic.com/~lynn/2007l.html#52 Drums: Memory or Peripheral?
https://www.garlic.com/~lynn/2009e.html#41 "A foolish consistency" or "3390 cyl/track architecture"
https://www.garlic.com/~lynn/2010k.html#17 Documenting the underlying FBA design of 3375, 3380 and 3390?
https://www.garlic.com/~lynn/2011.html#57 Speed of Old Hard Disks
https://www.garlic.com/~lynn/2011.html#60 Speed of Old Hard Disks
https://www.garlic.com/~lynn/2011.html#69 Speed of Old Hard Disks
https://www.garlic.com/~lynn/2011j.html#47 Graph of total world disk space over time?
https://www.garlic.com/~lynn/2012o.html#58 ISO documentation of IBM 3375, 3380 and 3390 track format
https://www.garlic.com/~lynn/2012o.html#60 ISO documentation of IBM 3375, 3380 and 3390 track format

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Mon, 11 Mar 2013 10:26:31 -0400
re:
https://www.garlic.com/~lynn/2013c.html#50 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#77 relative mainframe speeds, was What Makes an Architecture Bizarre?

some other random disk refs:
http://forums.legitreviews.com/about16883.html
http://www-03.ibm.com/ibm/history/exhibits/storage/storage_3330.html
http://www.staff.ncl.ac.uk/roger.broughton/museum/DASD/200427.htm

--
virtualization experience starting Jan1968, online at home since Mar1970

Still not convinced about the superiority of mainframe security vs distributed?

Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Still not convinced about the superiority of mainframe security vs distributed?
Date: 11 Mar 2013
Blog: Enterprise Systems
re:
http://lnkd.in/hDdvMA
and
https://www.garlic.com/~lynn/2013c.html#75 Still not convinced about the superiority of mainframe security vs distributed?

note ... 360 had storage key "store" protect ... and also offered"fetch" protect as option. this is different than page protect mentioned upthread ... originally vm370 tried as substitute for the original 370 segment protect that was dropped (along with other features) trying to recover schedule retrofitting virtual memory to 370/165. As mentioned that it floundered in original attempt with 168 page protect because the engineers wanted to combine it with all the changes to support mvs assist ... which would result in having vm370 subsidize the changes for mvs assist (such ploys had been used before in software getting vm370 networking to subsidize jes2 networking) ... and the MVS RAS people only exhibited passing interest in the feature.

However, one of the c-language related exploits is incorrect length string in conjunction with "stack smashing" (long string with embedded rogue instructions and stack overlay so execution resumes with the rogue instructions).
https://en.wikipedia.org/wiki/Stack_buffer_overflow

hardware countermeasure has been instruction fetch protect (aka no-execute) ... it didn't stop data from being fetched from the area ... but the instruction fetch unit wouldn't fetch from the no-execute area. wiki reference that feature is available on modern processors and supported by modern software
https://en.wikipedia.org/wiki/Data_Execution_Prevention

it doesn't stop denial-of-service buffer overflow ... but it stops execution of rogue software via stack smashing.

as i mentioned up thread ... the issue of string processing is a c-language issue ... other programmig language implementations not having the epidemic of similar vulnerabilities (including the original mainframe tcp/ip product implemented in vs/pascal).

original 360 had separation of privileged and user state as well as storage protect keys ... but took a long time for early os/360 implementations to really enforce security infrastructures (any more than early PCs.) ... although in that timeframe, cp/67 on 360/67 was used for lots of sensitive environments ... reference gone 404 ... but lives on at wayback machine.
https://web.archive.org/web/20090117083033/http://www.nsa.gov/research/selinux/list-archive/0409/8362.shtml

as undergraduate in the 60s, i was doing lots of operating system stuff and i didn't learn about the above guys until much later ... but the vendor would periodically ask if i could do some stuff to the operating system ... and in retrospect, some of the requests may have originated from that community (note that cp67/vm370 genre is one of the few lineages that has had security designed & builtin starting with the original implementation done by the science center on 4th flr ... possibly consider some competition with the multics group that were on the 5th flr ... see reference to multics security evaluation upthread).

the original 801/risc (precursor to power and power/pc) ... also started out w/o supervisor/problem mode ... 801/risc romp chip originally was going to be used in the follow-on to the displaywriter ... running cpr with pl.8 compiler. cpr didn't need supervisor/problem mode in the hardware because cpr would only load valid pl.8 programs (for execution) and pl.8 would only generate correct programs (applications could execute all instructions ... including the supervisor type instructions). When the displaywriter follow-on was canceled, it was decided to retarget it for the unix workstation market .... this required retrofitting supervisor/problem state instruction execution.

this has linux-based chrome/os surviving latest hacking competition
http://tech2.in.com/news/software/chrome-os-withstands-hacks-to-keep-googles-3-million-bounty-safe/813942

while others didn't do as well
http://www.h-online.com/open/news/item/Pwn2Own-ends-with-all-attackers-winning-1819164.html

past posts mentioning buffer overflow
https://www.garlic.com/~lynn/subintegrity.html#overflow

misc. past posts mentioning no-execute &/or stack smashing:
https://www.garlic.com/~lynn/2004q.html#82 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#0 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005.html#3 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#25 360POO
https://www.garlic.com/~lynn/2005b.html#39 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#42 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005b.html#66 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#44 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005o.html#10 Virtual memory and memory protection
https://www.garlic.com/~lynn/2006d.html#8 IBM 610 workstation computer
https://www.garlic.com/~lynn/2006q.html#7 Linux More Secure on System z?
https://www.garlic.com/~lynn/2006s.html#64 Is the teaching of non-reentrant HLASM coding practices ever defensible?
https://www.garlic.com/~lynn/2007r.html#57 Translation of IBM Basic Assembler to C?
https://www.garlic.com/~lynn/2007t.html#9 How the pages tables of each segment is located
https://www.garlic.com/~lynn/2007t.html#21 How the pages tables of each segment is located
https://www.garlic.com/~lynn/2008f.html#64 Panic in Multicore Land

--
virtualization experience starting Jan1968, online at home since Mar1970

Still not convinced about the superiority of mainframe security vs distributed?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Still not convinced about the superiority of mainframe security vs distributed?
Date: 12 Mar 2013
Blog: Enterprise Systems
re:
http://lnkd.in/hDdvMA
and
https://www.garlic.com/~lynn/2013c.html#75 Still not convinced about the superiority of mainframe security vs distributed?
https://www.garlic.com/~lynn/2013c.html#79 Still not convinced about the superiority of mainframe security vs distributed?

There were a number of spinoffs from science center that started offering (secure) online commercial service bureau (first cp67 and some then moving to vm370; even moving up value chain to offering financial information ... customers included major competing wallstreet firms).

Another start up out on the west coast was TYMSHARE using VM370. TYMSHARE is noted for starting offering its vm370/cms online computer conference free to SHARE user group organization in aug1976, archive here
http://vm.marist.edu/~vmshare
sometimes(?) "404" ... but also at wayback machine
http://vm.marist.edu/~vmshare/

TYMSHARE then started development of capability-based secure (370-based) operating system called GNOSIS. In the mid-80s, when M/D bought TYMSHARE, I was brought in to audit GNOSIS as part of its spin-off to keykos. This has since gone through several generations and versions ... latest generation (on i86) was desgined for EAL7+ common criteria evaluation.
https://en.wikipedia.org/wiki/GNOSIS .
http://cap-lore.com/CapTheory/upenn/Gnosis/Gnosis.html ...

aka
https://en.wikipedia.org/wiki/CapROS

past posts mentioning gnosis, capros, etc.
https://www.garlic.com/~lynn/2000f.html#69 TSS ancient history, was X86 ultimate CISC? designs)
https://www.garlic.com/~lynn/2000g.html#22 No more innovation? Get serious
https://www.garlic.com/~lynn/2001b.html#73 7090 vs. 7094 etc.
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#35 Did AT&T offer Unix to Digital Equipment in the 70s?
https://www.garlic.com/~lynn/2001n.html#10 TSS/360
https://www.garlic.com/~lynn/2002f.html#59 Blade architectures
https://www.garlic.com/~lynn/2002g.html#4 markup vs wysiwyg (was: Re: learning how to use a computer)
https://www.garlic.com/~lynn/2002h.html#43 IBM doing anything for 50th Anniv?
https://www.garlic.com/~lynn/2002i.html#63 Hercules and System/390 - do we need it?
https://www.garlic.com/~lynn/2002j.html#75 30th b'day
https://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation
https://www.garlic.com/~lynn/2003h.html#41 Segments, capabilities, buffer overrun attacks
https://www.garlic.com/~lynn/2003j.html#20 A Dark Day
https://www.garlic.com/~lynn/2003k.html#50 Slashdot: O'Reilly On The Importance Of The Mainframe Heritage
https://www.garlic.com/~lynn/2003l.html#19 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#22 Secure OS Thoughts
https://www.garlic.com/~lynn/2003l.html#26 Secure OS Thoughts
https://www.garlic.com/~lynn/2003m.html#54 Thoughts on Utility Computing?
https://www.garlic.com/~lynn/2004c.html#4 OS Partitioning and security
https://www.garlic.com/~lynn/2004e.html#27 NSF interest in Multics security
https://www.garlic.com/~lynn/2004m.html#29 Shipwrecks
https://www.garlic.com/~lynn/2004m.html#49 EAL5
https://www.garlic.com/~lynn/2004n.html#41 Multi-processor timing issue
https://www.garlic.com/~lynn/2004o.html#33 Integer types for 128-bit addressing
https://www.garlic.com/~lynn/2005.html#7 How do you say "gnus"?
https://www.garlic.com/~lynn/2005b.html#6 [Lit.] Buffer overruns
https://www.garlic.com/~lynn/2005c.html#67 intel's Vanderpool and virtualization in general
https://www.garlic.com/~lynn/2005d.html#43 Secure design
https://www.garlic.com/~lynn/2005d.html#50 Secure design
https://www.garlic.com/~lynn/2005h.html#13 Today's mainframe--anything to new?
https://www.garlic.com/~lynn/2005k.html#30 Public disclosure of discovered vulnerabilities
https://www.garlic.com/~lynn/2005s.html#12 Flat Query
https://www.garlic.com/~lynn/2006k.html#37 PDP-1
https://www.garlic.com/~lynn/2006m.html#34 PDP-1
https://www.garlic.com/~lynn/2006p.html#13 What part of z/OS is the OS?
https://www.garlic.com/~lynn/2006s.html#7 Very slow booting and running and brain-dead OS's?
https://www.garlic.com/~lynn/2006w.html#42 vmshare
https://www.garlic.com/~lynn/2006y.html#11 Multiple mappings
https://www.garlic.com/~lynn/2006y.html#16 "The Elements of Programming Style"
https://www.garlic.com/~lynn/2007k.html#26 user level TCP implementation
https://www.garlic.com/~lynn/2007o.html#25 LAX IT failure: leaps of faith don't work
https://www.garlic.com/~lynn/2007s.html#17 Oddly good news week: Google announces a Caps library for Javascript
https://www.garlic.com/~lynn/2008b.html#24 folklore indeed
https://www.garlic.com/~lynn/2008b.html#50 How does ATTACH pass address of ECB to child?
https://www.garlic.com/~lynn/2008e.html#12 Kernels
https://www.garlic.com/~lynn/2008g.html#7 was: 1975 movie "Three Days of the Condor" tech stuff
https://www.garlic.com/~lynn/2008g.html#23 Doug Engelbart's "Mother of All Demos"
https://www.garlic.com/~lynn/2008h.html#14 Two views of Microkernels (Re: Kernels
https://www.garlic.com/~lynn/2008s.html#3 New machine code
https://www.garlic.com/~lynn/2009b.html#4 Possibility of malicious CPUs
https://www.garlic.com/~lynn/2009f.html#28 Opinion: The top 10 operating system stinkers
https://www.garlic.com/~lynn/2010d.html#84 Adventure - Or Colossal Cave Adventure
https://www.garlic.com/~lynn/2010g.html#9 Far and near pointers on the 80286 and later
https://www.garlic.com/~lynn/2010g.html#53 Far and near pointers on the 80286 and later
https://www.garlic.com/~lynn/2010j.html#75 What is the protocal for GMT offset in SMTP (e-mail) header
https://www.garlic.com/~lynn/2010q.html#63 VMSHARE Archives
https://www.garlic.com/~lynn/2011b.html#31 Colossal Cave Adventure in PL/I
https://www.garlic.com/~lynn/2011c.html#2 Other early NSFNET backbone
https://www.garlic.com/~lynn/2011d.html#71 Multiple Virtual Memory
https://www.garlic.com/~lynn/2011e.html#35 junking CKD; was "Social Security Confronts IT Obsolescence"
https://www.garlic.com/~lynn/2011i.html#37 Happy 100th Birthday, IBM!
https://www.garlic.com/~lynn/2011l.html#42 i432 on Bitsavers?
https://www.garlic.com/~lynn/2011l.html#55 Any candidates for best acronyms?
https://www.garlic.com/~lynn/2012i.html#39 Just a quick link to a video by the National Research Council of Canada made in 1971 on computer technology for filmmaking
https://www.garlic.com/~lynn/2012i.html#40 GNOSIS & KeyKOS
https://www.garlic.com/~lynn/2012i.html#43 Virtual address Memory Protection Unit
https://www.garlic.com/~lynn/2012i.html#53 Operating System, what is it?
https://www.garlic.com/~lynn/2012i.html#59 Operating System, what is it?
https://www.garlic.com/~lynn/2012k.html#57 1132 printer history
https://www.garlic.com/~lynn/2012l.html#57 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012m.html#7 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012p.html#38 There can be no System Security without System Integrity

--
virtualization experience starting Jan1968, online at home since Mar1970

Still not convinced about the superiority of mainframe security vs distributed?

Refed: **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Still not convinced about the superiority of mainframe security vs distributed?
Date: 12 Mar 2013
Blog: Enterprise Systems
re:
http://lnkd.in/hDdvMA
and
https://www.garlic.com/~lynn/2013c.html#75 Still not convinced about the superiority of mainframe security vs distributed?
https://www.garlic.com/~lynn/2013c.html#79 Still not convinced about the superiority of mainframe security vs distributed?
https://www.garlic.com/~lynn/2013c.html#80 Still not convinced about the superiority of mainframe security vs distributed?

Other trivia ... there was effort starting in the late 70s to converge a wide-variety of IBM's internal microprocessors to 801/risc ... this included the microprocessors used for low & mid-range 370s, various controllers, the original follow-on for s/38; the as/400, etc. For various reasons all these efforts floundered and several of the people left and went on to work on risc implementations at other vendors. One of the people that left had previously also been responsible for things like dual-address space feature on the 3033.

He later was one of the primary architects for Itanium (the original 64bit targeted to be replacement for i86 server platforms). It had a number of extra hardware security features ... but there was a big pullback from Itanium and it has never caught on. However, the architect, after he retired, went on to be co-founder of Secure64 ... which offers very high-integrity Itanium-based products.
http://www.prnewswire.com/news-releases/secure64-wins-2011-mission-critical-innovation-award-for-best-new-application-135571003.html

misc. past posts mentioning Itanium and/or Secure64:
https://www.garlic.com/~lynn/2001b.html#15 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#16 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#17 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001b.html#23 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
https://www.garlic.com/~lynn/2001f.html#42 Golden Era of Compilers
https://www.garlic.com/~lynn/2001j.html#12 OT - Internet Explorer V6.0
https://www.garlic.com/~lynn/2002f.html#14 Mail system scalability (Was: Re: Itanium troubles)
https://www.garlic.com/~lynn/2002f.html#15 Mail system scalability (Was: Re: Itanium troubles)
https://www.garlic.com/~lynn/2002f.html#18 Mail system scalability (Was: Re: Itanium troubles)
https://www.garlic.com/~lynn/2002j.html#32 Latency benchmark (was HP Itanium2 benchmarks)
https://www.garlic.com/~lynn/2002j.html#35 Latency benchmark (was HP Itanium2 benchmarks)
https://www.garlic.com/~lynn/2002j.html#74 Itanium2 power limited?
https://www.garlic.com/~lynn/2002j.html#77 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002k.html#2 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002k.html#6 IBM 327x terminals and controllers (was Re: Itanium2 power
https://www.garlic.com/~lynn/2002l.html#52 Itanium2 performance data from SGI
https://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
https://www.garlic.com/~lynn/2002m.html#75 New Book
https://www.garlic.com/~lynn/2003b.html#61 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#14 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#15 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#17 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#19 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#20 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#22 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#23 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#27 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#28 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#30 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#31 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#33 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#34 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#35 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#42 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#46 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#47 difference between itanium and alpha
https://www.garlic.com/~lynn/2003c.html#52 difference between itanium and alpha
https://www.garlic.com/~lynn/2003d.html#12 difference between itanium and alpha
https://www.garlic.com/~lynn/2003l.html#40 The real history of computer architecture: the short form
https://www.garlic.com/~lynn/2003p.html#14 64 bits vs non-coherent MPP was: Re: Itanium strikes again
https://www.garlic.com/~lynn/2004k.html#44 Wars against bad things
https://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessor
https://www.garlic.com/~lynn/2005q.html#5 What ever happened to Tandem and NonStop OS ?
https://www.garlic.com/~lynn/2006.html#39 What happens if CR's are directly changed?
https://www.garlic.com/~lynn/2006b.html#28 Multiple address spaces
https://www.garlic.com/~lynn/2006c.html#9 Mainframe Jobs Going Away
https://www.garlic.com/~lynn/2006e.html#0 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006e.html#1 About TLB in lower-level caches
https://www.garlic.com/~lynn/2006i.html#33 virtual memory
https://www.garlic.com/~lynn/2006o.html#67 How the Pentium Fell Short of a 360/195
https://www.garlic.com/~lynn/2006q.html#8 Is no one reading the article?
https://www.garlic.com/~lynn/2006r.html#24 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006r.html#26 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006r.html#27 A Day For Surprises (Astounding Itanium Tricks)
https://www.garlic.com/~lynn/2006s.html#58 IA64 and emulator performance
https://www.garlic.com/~lynn/2006s.html#60 IA64 and emulator performance
https://www.garlic.com/~lynn/2006u.html#32 To RISC or not to RISC
https://www.garlic.com/~lynn/2006w.html#14 IBM sues maker of Intel-based Mainframe clones
https://www.garlic.com/~lynn/2007k.html#1 VLIW pre-history
https://www.garlic.com/~lynn/2007k.html#6 VLIW pre-history
https://www.garlic.com/~lynn/2007k.html#7 VLIW pre-history
https://www.garlic.com/~lynn/2007k.html#14 Some IBM 3033 information
https://www.garlic.com/~lynn/2007k.html#27 user level TCP implementation
https://www.garlic.com/~lynn/2007p.html#55 Is Parallel Programming Just Too Hard?
https://www.garlic.com/~lynn/2007u.html#73 New, 40+ yr old, direction in operating systems
https://www.garlic.com/~lynn/2008d.html#54 Throwaway cores
https://www.garlic.com/~lynn/2008e.html#41 IBM announced z10 ..why so fast...any problem on z 9
https://www.garlic.com/~lynn/2008g.html#49 IBM emulator for ICL 1900
https://www.garlic.com/~lynn/2008g.html#56 performance of hardware dynamic scheduling
https://www.garlic.com/~lynn/2008g.html#60 Different Implementations of VLIW
https://www.garlic.com/~lynn/2008g.html#61 performance of hardware dynamic scheduling
https://www.garlic.com/~lynn/2008h.html#29 DB2 & z/OS Dissertation Research
https://www.garlic.com/~lynn/2008i.html#52 Microsoft versus Digital Equipment Corporation
https://www.garlic.com/~lynn/2008j.html#10 We're losing the battle
https://www.garlic.com/~lynn/2008k.html#78 Secure64 Develops First Automated DNSSEC Signing Application to Help Secure the Internet Worldwide
https://www.garlic.com/~lynn/2008k.html#79 Larrabee details: Yes, it is based on the Pentium. :-)
https://www.garlic.com/~lynn/2008l.html#45 z/OS BIND9 DNS Vulnerable to Cache Poisoning Attack Problem?
https://www.garlic.com/~lynn/2009d.html#35 Future System
https://www.garlic.com/~lynn/2009g.html#69 The coming death of all RISC chips
https://www.garlic.com/~lynn/2009o.html#29 Justice Department probing allegations of abuse by IBM in mainframe computer market
https://www.garlic.com/~lynn/2009o.html#58 Rudd bucks boost IBM mainframe business
https://www.garlic.com/~lynn/2009p.html#6 Is it time to stop research in Computer Architecture ?
https://www.garlic.com/~lynn/2009p.html#58 MasPar compiler and simulator
https://www.garlic.com/~lynn/2010c.html#29 search engine history, was Happy DEC-10 Day
https://www.garlic.com/~lynn/2010g.html#32 Intel Nehalem-EX Aims for the Mainframe
https://www.garlic.com/~lynn/2010h.html#2 Far and near pointers on the 80286 and later
https://www.garlic.com/~lynn/2010h.html#10 Far and near pointers on the 80286 and later
https://www.garlic.com/~lynn/2010h.html#13 OS/400 and z/OS
https://www.garlic.com/~lynn/2010h.html#60 Itanium had appeal
https://www.garlic.com/~lynn/2010h.html#86 Itanium had appeal
https://www.garlic.com/~lynn/2010i.html#3 Processors stall on OLTP workloads about half the time--almost no matter what you do
https://www.garlic.com/~lynn/2010j.html#49 Article says mainframe most cost-efficient platform
https://www.garlic.com/~lynn/2010n.html#68 PL/1 as first language
https://www.garlic.com/~lynn/2010n.html#71 Fujitsu starts shipping 800 rack 80,000 chip 'K' supercomputer
https://www.garlic.com/~lynn/2011c.html#18 If IBM Hadn't Bet the Company
https://www.garlic.com/~lynn/2011c.html#25 If IBM Hadn't Bet the Company
https://www.garlic.com/~lynn/2011c.html#66 RISCversus CISC
https://www.garlic.com/~lynn/2011d.html#50 Itanium at ISSCC
https://www.garlic.com/~lynn/2011e.html#93 Itanium at ISSCC
https://www.garlic.com/~lynn/2011f.html#1 Itanium at ISSCC
https://www.garlic.com/~lynn/2011f.html#17 New job for mainframes: Cloud platform
https://www.garlic.com/~lynn/2011f.html#39 At least two decades back, some gurus predicted that mainframes would disappear in future and it still has not happened
https://www.garlic.com/~lynn/2011i.html#61 Joint Design of Instruction Set and Language
https://www.garlic.com/~lynn/2011o.html#75 Has anyone successfully migrated off mainframes?
https://www.garlic.com/~lynn/2012g.html#38 Should IBM allow the use of Hercules as z system emulator?
https://www.garlic.com/~lynn/2012j.html#26 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
https://www.garlic.com/~lynn/2012j.html#33 Is VAX decoding really that bad
https://www.garlic.com/~lynn/2012n.html#21 8-bit bytes and byte-addressed machines

--
virtualization experience starting Jan1968, online at home since Mar1970

Retailer Sues Visa Over $13 Million "Fine" for Being Hacked

From: lynn@garlic.com
Subject: Retailer Sues Visa Over $13 Million "Fine" for Being Hacked
Date: 12 Mar 2013
Blog: Financial Crime Risk, Fraud and Security
Retailer Sues Visa Over $13 Million "Fine" for Being Hacked
http://www.wired.com/threatlevel/2013/03/genesco-sues-visa/
Hacked retailers up in arms over $13 million 'fine', Visa lands up in court; Visa is being hit with a lawsuit after retailers decided to fight penalties imposed by credit card companies for data breaches.
http://www.zdnet.com/hacked-retailers-up-in-arms-over-13-million-fine-visa-lands-up-in-court-7000012468/
Retailer sues Visa over data breach penalties
http://www.finextra.com/News/FullStory.aspx?newsitemid=24623

....

In the mid-90s we were invited to participate in the x9a10 financial standard working group and co-authored the x9.59 financial transaction standard. One of the objectives of x9.59 was to make the common information in transactions unusable by crooks for performing fraudulent financial transactions (eliminate the motivation for performing majority of breaches as well as any threat/risk in such breaches)

we've since characterized the current paradigm
• the value of the information in a transaction to the merchant is the profit from the transaction (possibly a couple dollars, to the transaction processor possibly a couple cents). however the value of the transaction to the crook is the credit limit and/or account balance (possibly a couple hundred or couple thousand dollars). As a result the crooks may be able to outspend attacking the system by a factor of 100 times (as merchants/processors can spend defending the system).

• the information in a transaction is required in dozens of business processes at millions of locations around the world. in the current paradigm, the transaction information has to be kept completely confidential and never divulged. The diametrically opposing requirements will mean that even if the planet is buried under miles of information hiding encryption, it won't be able to stop the information leakage.


....

x9.59 reference
https://www.garlic.com/~lynn/x959.html#x959

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Tue, 12 Mar 2013 14:57:52 -0400
Ahem A Rivet's Shot <steveo@eircom.net> writes:
Well the TCP/IP stack is not a *small* amount of code, but yes networking has long since stopped being a performance issue. I recall in the mid 90s being surprised to discover that the storage I was using to run compiles on was actually in Chicago while the workstation I was using was in Phoenix - I was using that storage because it was *faster* than the disc in the box I was using. Apparently the sites were linked by multiple ganged T3 connections and the storage was mapped out of a large high performance RAID, I suspect the limiting factor was the 100Mbps fast ethernet on the workstation.

at IETF meeting late 80s in san jose ... presentation related to gbit/link ... typical tcp/ip stack was 5 data copies and 5k instruction ... but the router code pathlenth was being reduced from something like 130 instructions to 80-some. I was on the XTP technical advisery board that was doing design for pipelined enhancements eliminating all data copies (with outboard processing) ... as well as reliable transfer in minimum of 3exchanges ... compared to minimum 7exchanges for tcp. some past posts
https://www.garlic.com/~lynn/subnetwork.html#xtphsp

this would come to bite HTTP in the mid-90s ... layering a packet oriented protocol on top of session oriented tcp. there was period ramp-up in traffic on major http servers where finwait processing was starting to consume 95% of processor. netscape was constantly adding backend servers for people to download latest version of the browser ... this was before modification to boundary router that would do transparent dynamic load-balancing across backend servers (initial router hack was done a little later for google's boundary routers).

netscape eventually installed a sequent server that first solved the (finwait) problem. sequent had claimed it originally addressed finwait when it had customers with 20,000 concurrent telnet sessions (i.e. most tcp/ip implementations assumed relative long-lived sessions with infrequent session closes ... so finwait processing wasn't very optimized).

more recent

China's next-generation internet is a world-beater
http://www.newscientist.com/article/mg21729075.800-chinas-nextgeneration-internet-is-a-worldbeater.html

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Wed, 13 Mar 2013 16:31:12 -0400
hancock4 writes:
"Quite large" is an understatement. As others have pointed out, mainframe CPUs are much, much faster than in the past. I think it's safe to say an IBM mainframe of today is easily doing the work of perhaps ten or more mainframes of say 20 years ago. So the installed base is much higher.

As to lines of code in service, there is a _tremendous_ amount of legacy code still running today. Most of it is running untouched, with perhaps some minor mainteance around the ages.

As other people here and articles have noted, some financial center transactions represent a heavy mainframe load that could not be accomplished in any other way.

I have no idea of where COBOL and the IBM System/360 architecture will be in the future. Frankly, ten years ago I thought S/360 would not survive for its 50th anniversary except in isolated situations. I thought all the old jumbo COBOL enterprise applications would be rewritten. But COBOL and the classic mainframe are still with us in a substantial way.


however, i've frequently commented that any of the significant numbers of megadatacenters, individually, have more processing power than all the mainframes in existance today. some of the recent publicized public cloud "on-demand") supercomputers that were spun for couple hrs (on-demand) ... have probably had more processing power than the aggregate of all current worldwide mainframe processing

re:
https://www.garlic.com/~lynn/2013c.html#59 Why Intel can't retire X86

recent generations max mainframe model configuration
z900, 16 processors, 2.5BIPS (156MIPS/proc), Dec2000
z990, 32 processors, 9BIPS, (281MIPS/proc), 2003
z9, 54 processors, 18BIPS (333MIPS/proc), July2005
z10, 64 processors, 30BIPS (469MIPS/proc), Feb2008
z196, 80 processors, 50BIPS (625MIPS/proc), Jul2010
EC12, 101 processors, 75BIPS (743MIPS/proc), Aug2012


from 2000 to 2008, individual processor speed tripled and max. number of processors quadrupled (aggregate going from 2.5BIPS to 30BIPS).

from 2008 to 2012, individual processor speed and max number of processors both increased about 60%. over 12yr period, aggregate processing went from 2.5BIPS to 75BIPS (factor of 30 times).

note however, lots of recent mainframe sales have been upgrades ... and total IBM annual mainframe revenue recently has been equivalent of approx. 180 max. configured z196 (at $28M per) ... so that there can't have been any significant increase in mainframe processing capacity over at the last four yrs.

I've periodically commented about the billions spent in the 90s to switch from overnight batch cobol applications (in the financial industry) to large numbers of parallel "killer micros" ... that failed miserably ... in part of attempting to use new technology w/o adequately having done any speeds&feeds analysis ... relying on parallelizing technology that had factor of 100 times slowdown (compared to cobol batch) ... that totally swamped any anticipate throughput increase.

On the other hand, a couple yrs ago I participated in taking some new technology to financial industry organications that showed it could completely replace the overnight batch cobol with highly parallel technology along with significant throughput increases. It relied on the significant advances in parallelized RDBMS throughput that has happened over the past two decades ... resulting in only a 3-5 times throughput hit (compared to cobol batch) ... but the non-mainframe cluster hardware more than offsets the RDBMS hit. The technology is also at a significant higher level of abstraction greatly reducing lifetime software engineering and programming costs ... as well as development change elapsed time. They currently have a few i86 servers with a workload that simulates the total exchange activity processing in less than real time (they can do straight-through complete exchange transactions faster than the exchange generates transactions). recent post mentioning straight-through processing and overnight batch
https://www.garlic.com/~lynn/2013b.html#42 COBOL will outlive us all

At the time, there was initially very favorable reception ... but then it was all suspended. The observation was that there was still significant number of financial IT executives carrying the scars from the failed efforts in the 90s (and it would have to wait for a new generation).

some i86 values from 2000-2012
https://en.wikipedia.org/wiki/Million_instructions_per_second
2000 3.5BIPS
2003 7.5BIPS, 9.7BIPS,
2005 12BIPS, 15BIPS 19BIPS
2008 60BIPS, 82BIPS
2010 147BIPS (8core)
2011 177BIPS (8core)
2012 527BIPS ... e5-2600, 2chip, 16cores, 33BIPS/core


ibm has base list price of $1815 for e5-2600 blade or $3.44/BIPS (compared to $560,000/BIPS for z196). large public clouds are claiming doing their own blades for 1/3rd cost of brand name blades ... which possibly lowers it to nearly $1/BIPS.

IBM says that total mainframe revenue is 6.25 times the mainframe hardware processor (add in software, services, storage) ... so somebody buying a $28M z196 will being paying IBM an avg total $175M for the whole system (or $3.5M/BIPS ... effectively 3,500,000 times that of public cloud BIPS).

also peak z196 I/O benchmark is 2M IOPS using 104 FICON channels (i.e. mainframe protocol mapped over 104 FCS) using 14 SAPs ... SAPs are rated at 2.2M SSCH/sec running all at 100% busy ... but recommendation is to keep SAP busy at 70% busy (or less) aka 1.5M SSCH/sec. ... compared to recently announced (native) FCS for e5-2600 claimed to be capable of over 1M IOPS (aka two such FCS for e5-2600 may beat peak I/O z196 using 104 FICON).

recent posts mentioning e5-2600, ficon, mainframes, etc:
https://www.garlic.com/~lynn/2013.html#9 Is Microsoft becoming folklore?
https://www.garlic.com/~lynn/2013.html#10 From build to buy: American Airlines changes modernization course midflight
https://www.garlic.com/~lynn/2013.html#16 From build to buy: American Airlines changes modernization course midflight
https://www.garlic.com/~lynn/2013.html#17 Still think the mainframe is going away soon: Think again. IBM mainframe computer sales are 4% of IBM's revenue; with software, services, and storage it's 25%
https://www.garlic.com/~lynn/2013.html#38 DEC/PDP minicomputers for business in 1968?
https://www.garlic.com/~lynn/2013.html#40 Searching for storage (DASD) alternatives
https://www.garlic.com/~lynn/2013.html#55 IBM reveals a monster 36-core mainframe module
https://www.garlic.com/~lynn/2013.html#77 OT: but hopefully interesting - Million core supercomputer
https://www.garlic.com/~lynn/2013b.html#5 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#6 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#7 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#8 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#10 FW: mainframe "selling" points -- Start up Costs
https://www.garlic.com/~lynn/2013b.html#15 A Private life?
https://www.garlic.com/~lynn/2013b.html#24 New HD
https://www.garlic.com/~lynn/2013b.html#25 Still think the mainframe is going away soon: Think again. IBM mainframe computer sales are 4% of IBM's revenue; with software, services, and storage it's 25%
https://www.garlic.com/~lynn/2013b.html#45 Article for the boss: COBOL will outlive us all
https://www.garlic.com/~lynn/2013b.html#55 Dualcase vs monocase. Was: Article for the boss
https://www.garlic.com/~lynn/2013c.html#60 Why Intel can't retire X86
https://www.garlic.com/~lynn/2013c.html#62 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#63 What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#67 relative speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#68 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#77 relative mainframe speeds, was What Makes an Architecture Bizarre?

--
virtualization experience starting Jan1968, online at home since Mar1970

Digital Certificates Hide Malware

From: lynn@garlic.com
Subject: Digital Certificates Hide Malware
Date: 13 Mar 2013
Blog: Google+
re:
https://plus.google.com/u/0/102794881687002297268/posts/4igvfaoKGQs

"Digital Certificates Hide Malware; Fraudsters' Fake Companies Fool Cert Authorities"
http://www.bankinfosecurity.com/digital-certificates-hide-malware-a-5592

.... 20yrs ago something similar was characterized as crooks using "front" companies to obtain legitimate digital certificates (as opposed to "fake" companies)

I've proselytized extensively about two-party public key going back to early 90s ... including having dozens of patents on the subject (all assigned) ... and co-authored financial industry transaction standard that is digitally signed ...
https://www.garlic.com/~lynn/x959.html

some recent posts:
https://www.garlic.com/~lynn/2013.html#39 ICSF Symmetric Key being sent to a non-zOS system
https://www.garlic.com/~lynn/2013c.html#2 Legal Lessons from PATCO Fraud Case
https://www.garlic.com/~lynn/2013c.html#34 The United States is leaking 1TB of data daily to foreign countries
https://www.garlic.com/~lynn/2013c.html#75 Still not convinced about the superiority of mainframe security vs distributed?

--
virtualization experience starting Jan1968, online at home since Mar1970

A Matter of Mindset: Iraq, Sequestration and the U.S. Army

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: A Matter of Mindset: Iraq, Sequestration and the U.S. Army
Date: 13 Mar 2013
Blog: Facebook
re:
https://www.garlic.com/~lynn/2013c.html#16 A Matter of Mindset: Iraq, Sequestration and the U.S. Army
https://www.garlic.com/~lynn/2013c.html#28 A Matter of Mindset: Iraq, Sequestration and the U.S. Army
https://www.garlic.com/~lynn/2013c.html#45 A Matter of Mindset: Iraq, Sequestration and the U.S. Army

from game theory, gaming the system, spreading Success Of Failure, fabricating justification for iraq invasion, etc

Over $8B of the Money You Spent Rebuilding Iraq Was Wasted Outright
http://www.wired.com/dangerroom/2013/03/iraq-waste/
Iraq: $60 billion and nothing to show
http://www.upi.com/Top_News/US/2013/03/06/Iraq-60-billion-and-nothing-to-show/UPI-24481362577184/

what could have been done instead for that $60B???

SIGIR Says "At Least" $8 Billion Lost in Iraq
http://www.pogo.org/blog/2013/03/20130308-sigir-says-at-least-8-billion-dollars-lost-in-Iraq.html

it isn't exactly new news, item from 2007: $12B in shrink wrapped $100s
http://www.theguardian.com/world/2007/feb/08/usa.iraq1

and in 2010: U.S. can't account for $8.7 billion of Iraq's money: audit
http://www.reuters.com/article/2010/07/27/us-iraq-usa-spending-idUSTRE66Q55620100727

pallets with billions in shrink wrapped $100 bills disappearing to fraud in Iraq

The Road Not Traveled in Iraq; Ten years after the Iraq invasion, a diplomatic insider reminds why it didn't have to go the way it did.
http://www.slate.com/articles/video/slate_v/2013/03/iraq_war_anniversary_what_went_wrong_reconsidered_10_years_later.html

... aka even if you believed the fabrication about WMDs ... there were still better ways than invasion.

and then there is: What Went Wrong In Afghanistan?
http://warnewsupdates.blogspot.com/2013/03/what-went-wrong-in-afghanistan.html

The Tragic Story Of Outpost Restrepo Sums Up The Whole Afghan War
http://www.businessinsider.com/outpost-restrepo-2013-3

and back to Iraq, son-in-law 1st tour was Fallujah 2004-2005, 2nd tour was Baqubah ... this book claims worse than Fallujah
https://www.amazon.com/Battle-Baqubah-Killing-Our-ebook/dp/B007VBBS9I/

(supposedly insurgents learned a lot in Fallujah) ... also this blog
http://www.michaelyon-online.com/index.php?option=com_content

How Bush Used PR to Conceal Massive Ethnic Cleansing in Baghdad; The Myth of the Surge
http://www.counterpunch.org/2013/03/13/the-myth-of-the-surge/ From El

Salvador to Iraq: Washington's man behind brutal police squads
http://www.guardian.co.uk/world/2013/mar/06/el-salvador-iraq-police-squads-washington

--
virtualization experience starting Jan1968, online at home since Mar1970

Not the Navy's Favorite Artist Rendering

Refed: **, - **, - **, - **, - **
From: lynn@garlic.com
Subject: Not the Navy's Favorite Artist Rendering
Date: 13 Mar 2013
Blog: Facebook
Not the Navy's Favorite Artist Rendering
http://nation.time.com/2013/03/12/not-the-navys-favorite-artist-rendering/

from above:
"The aircraft carrier is in danger of becoming like the battleships it was originally designed to support: big, expensive, vulnerable -- and surprisingly irrelevant to the conficts of the time," Hendrix writes. "This outcome has become more likely as the Navy continues to emphasize manned carrier aircraft at the expense of unmanned missiles and aircraft."

.. snip ...

Surface Combat Fleets: Obsolete?
http://thediplomat.com/the-naval-diplomat/2013/03/13/surface-combat-fleets-obsolete/

Navy captain: Time to deep-six the old school manned aviation carrier -- before long-range Chinese missiles do it for us
http://ricks.foreignpolicy.com/posts/2013/03/13/navy_captain_time_to_deep_six_the_old_school_manned_aviation_carrier_before_long_ra

Deceptive marketing practice: F-35 blocks
http://elpdefensenews.blogspot.com/2013/03/deceptive-marketing-practice-f-35-blocks.html

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Thu, 14 Mar 2013 09:48:20 -0400
Robert Wessel <robertwessel2@yahoo.com> writes:
You've posted numbers like these before. Unfortunately you're comparing (mostly) theoretical x86 peak MIPS to semi-actual S/370 MIPS. Or you're quoting something worthless like Dhrystone MIPS. For a single E5-2600 (say 3.1GHz mode) running a commercial workload, you should probably expect 3000-4000 MIPS. And S/370 does have an advantage in the amount of work performed per instruction, so you might want to (generously) give S/370 a factor of two advantage on commercial type loads.

But for compute performance on commercial loads, it would be semi-reasonable to call a 101 core EC12 as about triple the performance of a two socket E5-2687. The memory system gives the EC12 a big advantage too, but only on the right workload.

But that factor of ~15 doesn't really impact your cost comparisons.

OTOH, for HPC style loads, with vectorizable code, you've got a reasonable shot at getting to your 33BIPS number on x86, but that's a workload nobody does on an EC12.


re:
https://www.garlic.com/~lynn/2013c.html#84 What Makes an Architecture Bizarre?

Dhrystone MIPS is number of Dhrystone iterations prorated by the number of Dhrystone iterations of 370/158 presumed to be 1MIPS ... so it isn't directly instructions executed per second ... it is prorated amount of specific kind of work compared to the amount of work done by 370/158.

e5-2600 rated at 527BIPS also has a 315GFLOPS rating (20GFLOPS/processor)

part of the issue is that there are lack of standardized benchmark numbers for IBM mainframes ... vendors do standard benchmark for the mainline products ... even IBM does for their i86 and power products ... but it has been difficult to find any kind of standardized benchmark numbers for IBM mainframe.

Transaction Processing Performance Council
http://www.tpc.org/
TPC-C
http://www.tpc.org/tpcc/results/tpcc_perf_results.asp

and

Standard Performance Evaluation Corporation
http://www.spec.org/
SPEC CPU2006
http://www.spec.org/cpu2006/results/

recnt posts mentioning tpc.org and/or spec.org
https://www.garlic.com/~lynn/2012.html#23 21st Century Migrates Mainframe with Clerity
https://www.garlic.com/~lynn/2012d.html#64 Layer 8: NASA unplugs last mainframe
https://www.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
https://www.garlic.com/~lynn/2012i.html#16 Think You Know The Mainframe?
https://www.garlic.com/~lynn/2012i.html#89 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
https://www.garlic.com/~lynn/2012j.html#34 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
https://www.garlic.com/~lynn/2012l.html#39 The IBM zEnterprise EC12 announcment
https://www.garlic.com/~lynn/2012l.html#41 The IBM zEnterprise EC12 announcment
https://www.garlic.com/~lynn/2012l.html#42 I.B.M. Mainframe Evolves to Serve the Digital World
https://www.garlic.com/~lynn/2012l.html#100 Blades versus z was Re: Turn Off Another Light - Univ. of Tennessee
https://www.garlic.com/~lynn/2012m.html#28 I.B.M. Mainframe Evolves to Serve the Digital World
https://www.garlic.com/~lynn/2012o.html#11 Mainframes are still the best platform for high volume transaction processing
https://www.garlic.com/~lynn/2013b.html#6 mainframe "selling" points
https://www.garlic.com/~lynn/2013b.html#25 Still think the mainframe is
going away soon: Think again. IBM mainframe computer sales are 4% of IBM's revenue; with software, services, and storage it's 25%

--
virtualization experience starting Jan1968, online at home since Mar1970

relative mainframe speeds, was What Makes an Architecture Bizarre?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: relative mainframe speeds, was What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Thu, 14 Mar 2013 10:38:44 -0400
Rob Doyle <radioengr@gmail.com> writes:
I note that one of the earlier references did not calculate disk performance this way ... specifically avg. seek time.

It compared the avg. seek time of the older smaller disk with the avg. seek time of the newer much larger disk - and seemed to imply that disk performance had not increased very much. If one were to normalize this to the size of the disk (i.e., compare the avg. seek time to access the same 4 MB), the results would have looked very different.

The new disk was 3 or 4 orders of magnitude larger.

At some point, a /hypothetical/ larger disk could store all of the data of the smaller disk on a single cylinder. I guess that would be like fixed head disk. Zero seek time.


re:
https://www.garlic.com/~lynn/2013c.html#69 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What Makes an Architecture Bizarre?

the issue was on large system with high level of multi-tasking and concurrent random access operations ... larger number of arms gave higher level of concurrency. going to fewer arms for the same amount of data lowers concurrency.

so prorate the avg. accesses by disk arm by the amount of data under the arm. sort of the inverse is looking at total system IOPS ... i.e. avg. arm throughput times the number of arms (but that doesn't necessarily normalize it by the amount of data needing access)

3380 had twice the data capacity per arm (630MB) of 3350 (317.5MB), but avg. arm access only improved from 25ms to 16ms (40access/sec to 62access/sec, about 50% more access per second).

A 32 arm 3350 system would only need 16 arm 3380 for the same amount of data ... but the total IOPS would drop from 1280 to 992.

--
virtualization experience starting Jan1968, online at home since Mar1970

Query for Destination z article -- mainframes back to the future

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: lynn@GARLIC.COM (Anne & Lynn Wheeler)
Subject: Re: Query for Destination z article -- mainframes back to the future
Newsgroups: bit.listserv.ibm-main
Date: 14 Mar 2013 08:27:57 -0700
PaulGBoulder@AIM.COM (Paul Gilmartin) writes:
Don't underestimate the future.

The Y2K "crisis" might have been mitigated if more designers had said, "Hey, pretty soon we're going to need 4-digit years. Let's provide them now." I made such a suggestion for a product we were working on in 1987. It was brushed off as premature.

And much of the anguish of 24-bit to 31-bit address conversion might have been avoided if designers had thought to reserve the top 8 bits of addresses instead of using them for flags. Instead, many OS interfaces remain 24-bit constrained.

How many programmers are still using 31-bit branch instructions rather than 64 because z/OS doesn't support execution above the bar? This year.


there was a CENTURY discussion on the internal network early to mid-80s ... discussing the looming y2k problem. I've previously reposted somebody's post to the CENTURY discussion about similar/related issues at NASA:
https://www.garlic.com/~lynn/99.html#email841207
in this old Y2K thread
https://www.garlic.com/~lynn/99.html#24 BA Solves Y2K (Was: Re: Chinese Solve Y2K)

other past refs:
https://www.garlic.com/~lynn/2001n.html#74 The demise of compaq
https://www.garlic.com/~lynn/2009n.html#53 Long parms...again
https://www.garlic.com/~lynn/2010i.html#65 Of interest to the Independent Contractors on the list
https://www.garlic.com/~lynn/2010m.html#47 OT: Found an old IBM Year 2000 manual
https://www.garlic.com/~lynn/2010o.html#41 60 Minutes News Report:Unemployed for over 99 weeks!

misc. references to the internal network (larger than the arpanet/internet from just about the beginning until sometime late '85 or early '86)
https://www.garlic.com/~lynn/subnetwork.html#internalnet

other Y2K trivia ... one of the too-big-to-fail financial institutions had outsourced much of their Y2K remediation to the lowest bidder ... in this case a software company located it in the Brighton Beach area of Brooklyn. It wasn't until it was long over that they found out it was a front for an ethnic criminal organization (interesting hacks were found in various places that would trigger unlogged wire transfers to various places around the world).

--
virtualization experience starting Jan1968, online at home since Mar1970

What Makes an Architecture Bizarre?

Refed: **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **, - **
From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: What Makes an Architecture Bizarre?
Newsgroups: comp.arch, alt.folklore.computers
Date: Thu, 14 Mar 2013 14:12:48 -0400
re:
https://www.garlic.com/~lynn/2013c.html#69 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#74 relative mainframe speeds, was What Makes an Architecture Bizarre?
https://www.garlic.com/~lynn/2013c.html#89 relative mainframe speeds, was What Makes an Architecture Bizarre?

one of the things is that $$$/BIPS have dropped so drastically in large cloud megadatacenters ... that other factors have become significant operational costs. the big megadatacenters have been pioneers in optimizing cooling & power costs ... as those costs have become a larger and larger component of operation.

the $$$/BIPS have dropped so far that the large cloud megadatacenters are able to provision for significant amount of idle, on-demand capacity ... as long as the power&cooling costs also drop close to zero while idle.

in contrast mainframe costs are still so high that operational cost optimization is focused on 100% processor utilization ... although even mainframe now has software, services and storage 5.25 times the computer hardware ... so even mainframes may do some amount of configuration optimization to minimize their software licensing costs.

topic drift and computer folklore

60s & early 70s, mainframe computers were rented and rental charges were based on "cpu meter" ... that ran whenever the processor and/or i/o channels were busy. resource use was accounted for and billed to users as means of recovering datacenter costs.

there was desire to expand online cp67 service to 7x24 ... however, to attract the 7x24 use, it was necessary to keep the system up 7x24. however, 7x24 availability would mean that the "cpu meter" ran all the time, even when there was little or no use (needed to bill in order to recover datacenter costs and justify 7x24 availability).

as a result in the 60s, there was lots of work on cp67 to minimize offshift datacenter costs (as part of enabling 7x24 service availability). part of this was a lot of work on cp67 allowing for offshift "dark-room" operation (no operators in the datacenter). another was a hack to terminal i/o channel programs. normally the cpu meter would run even if the cpu was idle as long as there was an active channel program. You needed an active channel program in order to support incoming data from users. A hack was done with the terminal "PREPARE" CCW which would allow channel to go idle (and "cpu meter" to stop if there was no other activity). This drastically cut the cost of being able to have the system available 7x24.

Now, 360&370 "cpu meters" had characteristic that all (cpu and channel) activity had to be idle for at least 400milliseconds for the "cpu meter" to actually stop. MVS had a timer-driven task set for 400millisecond interval that would do some sort of housekeeping task ... but primarily guaranteed the "cpu meter" would never go idle in MVS systems (this was left in place long after mainframes had been converted to sales ... and cpu meter was no longer used for rental charges).

misc. past posts mentioning online system operation
https://www.garlic.com/~lynn/submain.html#timeshare

--
virtualization experience starting Jan1968, online at home since Mar1970



previous, next, index - home