Note Sarbanes-Oxley was passed in the wake of ENRON & Worldcom
... claims that it would prevent something similar from ever happening
again. However, there were jokes at the time that the only effect
would be increased business for auditors and wouldn't actual (since it
required action on the part of SEC). More recently seen on the
internet ENRON was dry run and worked so well that it has become
institutionalized

There were also comments at the time that possibly the only part of
SOX was the stuff supporting whistle-blowers ... but that would also
require SEC to do something. In the congressional hearings into Madoff
... the person that had tried unsuccessful for a decade to get SEC to
do something about Madoff (SEC was finally forced to do something when
he turned himself in), testified that tips (whistle-blowers) turn up
13 times more fraud than audits. Also that SEC has no "tip" line but
has a 1-800 number for corporations to complain about audits.

... and then there is this (from year ago): SEC Whistleblower: Feds
Destroyed Evidence Of Thousands Of Wall Streets' Worst Crimes
http://blog.alexanderhiggins.com/2011/08/17/sec-whistleblower-feds-destroyed-evidence-thousands-wall-streets-worst-crimes-60321/

Time to choose the Knights of 2012

From: lynn@garlic.com (Lynn Wheeler)
Date: 18 Aug, 2012
Subject: Time to choose the Knights of 2012
Blog: Order of Knights of VM

The precursor was TOOLSRUN on the ibm internal network starting in the
early 80s. It could operate in both usenet news-like mode as well in
mailing list mode. I had been blamed for online computer conferencing
on the internal network (larger than arpanet/internet from just about
the beginning until late '85 or early '86). Folklore is that when the
executive committee was told about computer conferencing (and the
internal network), 5of6 wanted to fire me. I had been doing
semi-automated stuff ... but then the corporation launched
investigations into the activity. One of the results was TOOLSRUN and
officially sanctioned newsgroups/discussion (with moderation).

Reference from IBM Jargon:
Tandem Memos - n. Something constructive but hard to control; a fresh
of breath air (sic). That's another Tandem Memos. A phrase to worry
middle management. It refers to the computer-based conference (widely
distributed in 1981) in which many technical personnel expressed
dissatisfaction with the tools available to them at that time, and
also constructively criticised the way products were are
developed. The memos are required reading for anyone with a serious
interest in quality products. If you have not seen the memos, try
reading the November 1981 Datamation summary.

somewhere along the way, after the investigations into computer
conferencing ... TOOLSRUN was pressed into service for the officially
sanctioned and moderated news/discussion groups.

I was then doing HSDT internally (T1 & faster links) ... and working
on speeding operations. T1 full-duplex was 300kbyte/sec sustained
... and I figured I needed ten times that throughput. misc. past posts
mentioning hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt

One of the things to get that throughput (for vnet/rscs) was rewrite
vm370 spool in vs/pascal running in a virtual machine (some slight of
hand to make it faster than assembler that ran supervisor in the vm370
kernel) ... supported contiguous allocation, multiblock read/writes
... and a psuedo asynchronous interface. Normal spool was 4k block
serialized synchronous and under loaded system vnet/rscs might be
lucky to get 4-8 4k blocks per second (maybe 30kbytes/sec instead of
3mbytes/sec).

Somewhere along the way somebody had introduced bug in vnet/rscs
driver in the compression code that eliminated S&F no-op records. For
high-speed links, compression was less thruput than
no-compression... so I turned that off also ... and all of a sudden
S&F no-op records re-appeared.

That got me into something of a *war* with the internal *owner* of
TOOSLRUN at the time ... since TOOLSRUN started rejecting traffic that
had the re-appeared S&F no-op records. I provided the fixes to
TOOLSRUN to correctly handle the re-appeared, multiple S&F no-op
records ... but there was a lot of resistance since initially nearly
all the internal VNET/RSCS drivers had the *bug*.

It was somewhat easier fixing the vm370 TCP/IP stack ... initially it
had approx. 44kbytes/sec using nearly whole 3090 processor. I did the
enhancements for RFC1044 support and in some testing at Cray research
got 4341 channel speed between 4341 & Cray machine ... using only
modest amount of 4341 processor.

whether or not you used the diagnose or CCWs ... the operations
translated into a serialized synchronous 4k spool operation
(effectively using path into the side of the paging system). large
number of CCWs could cut down on processor overhead but couldn't get
around the serialized synchronized 4k at a time (number of 4k byte
spool records per second).

for rewrite running in virtual machine ... I provided up/down calls
between the cp kernel into the spool virtual machine. for rscs/vnet
driver provided a new fastpath going for 3mbyte/sec sustained thruput
(for one thing, I couldn't have the rscs/vnet virtual machine
disabled/non-executable while waiting for each 4k spool read/write.).

One of the things with RSCS was it layered the infrastructure ... and
had lots of drivers to different infrastructures ... distinctly
different than JES2/NJI. NJI had so jumbled its implementation that
different releases of JES2 exchanging traffic would result in failure
and bringing down the associated MVS system. As a result internally, a
large library of NJI drivers evolved that were responsible for
converting to canonical NJI format ... and then the specific RSCS NJI
driver was started that corresponded to JES2 release it was directly
talking to (and responsible for converting NJI header to format
expected by that specific JES2). By the mid-80s, they had stopped
shipping native RSCS drivers to customers and customers only got the
NJI drivers (although native RSCS drivers continued to be used
internally because they were more efficient and had higher
throughput).

There was the infamous internal network incident where San Jose JES2
system resulted in MVS system in Hursley crashing. They eventually
blamed it on the RSCS system in Hursley failing to start the specific
NJI driver that would have reformated the NJI header for the Hursley
JES2 system (and prevented MVS from crashing) ... nobody thought to
blame JES2 for having a bad design.

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

First have to assume that the agenda of those at the top and the
interests of the organization are aligned. In the current corporate
culture ... there are enormous instances where it is mis-aligned. A
frequent theme is that the "C" executives are there for only short
period and looking to soak the organization for as much as they can. A
frequent & typical scenario was a decade ago a large manufacturing
corporation had majority of the bottom line coming from financial
services unit. The CFO was scheduled to depart and orchestrated the
sale of the financial unit just before leaving. This represented
long-term downside for the corporation bottom line ... but the CFO got
a percent of the sale.

continues here and starts out with the above Boyd quote:
http://www.challengemagazine.com/extra/054_069.pdf

There are two different Boyd issues/warnings here:

• ww2 military officers were indoctrinated in rigid, top-down,
command&control structure ... after ww2 lots of those officers
returned to civilian life and carried with them a culture of rigid,
top-down, command&control ... starting to contaminate all aspects
of US culture (not just military and corporations doing business with
military ... but also corporations having nothing to do with the
military ... as well as many other organizations). That represents a
general cultural contamination

• US military has had a 2nd generation warfare that heavily
relies on strategy of overwhelming resources along with enormous
industrial operation supporting the military. Once created, this
represents a very large and very hungry beast that wants to be
continuously feed ... even during periods when it is not
needed. Eisenhower warned about it ... it never wants to reduce the
amount that it is taking in ... it prefers to have it always increased
... even if it has to fabricate justifications for the funding. This
is Boyd's quote regarding Pentagon strategy ... funding is always the
number one thing.

The rigid, top-down, command&control contamination leaking out
into all aspects of American culture ... is separate from the creation
of the MICC beast that has a primary strategy of ever increasing
amounts of funding.

Boyd's comments about the contamination spreading into American
culture predates the modern internet (early 80s). The spinney(/boyd)
time 1983 article on ill-considered spending and Eisenhower's warning
about MICC predate the modern internet.

The culture of rigid, top-down, command&control was bringing down
US competitiveness ... and the every hungry MICC (military,
industrial, congressional complex ... references Eisenhower was
originally going to say but shortened it at the last minute) had an
aligned strategy to never stop the flow of funds ... even fabricating
reasons while it always needed to be increased.

tcp/ip is the technology basis for the modern internet, NSFNET
backbone was the operational basis for the modern internet and CIX was
the business basis for the modern internet. arpanet converted to
internetworking protocol on 1jan1983 ... at that time arpanet had
reach approx. 100 IMP network nodes and around 250 connected hosts (by
comparison the internal network ... which had been larger than the
arpanet from just about the beginning, was rapidly approaching 1000).

NSFNET backbone started out as part of congressional NSF funding for
supercomputing centers ... to maintain US competitive position
... with high-speed network connecting all the NSF supercomputers (and
providing interconnection for the TCP/IP infrastructure in the regions
around the centers). Started out the director of NSF was going to give
me $20M to build the network. Congress then cut the budget before I
got the money ... along with internal corporate politics kicked in
... that wanted to take it over. The director of NSF wrote the company
a letter, copying the CEO, but that just made the internal politics
worse (comments like what I already had running internally being at
least five years ahead of all submitted proposals, also made internal
politics worse).

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

Originally 8in floppy invented (by Shugart) for use to load software
for the 3830 disk controller ... was also used for loading microcode
for the 370. Consumers weren't exposed to it ... was purely inside the
machine dealt with by maintenance engineers. Then found its way into
other products
https://en.wikipedia.org/wiki/History_of_the_floppy_disk

I transferred from the cambridge science center to san jose research
in '77. They would let me wander around the plant site and play disk
engineer in bldgs. 14&15. Increasingly I would get con'ed into doing
stuff ... including being requested to be on conference calls with the
POK channel engineers. One of the explanations was that lots of the
san jose institutional knowledge about channels was with the senior
engineers that had been hired away by the mid-70s.

Early 80s, my brother was regional marketing rep for Apple (largest
physical area in conus). I would get to attend business dinners with
him when he was in town. I remember arguing design of MAC with the
engineers at dinner (before MAC was announced).

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

so the traditional is "not to be afraid of failure"; aka, "if you have
never failed, you have never attempted anything new"

large parts of MICC perpetuates "risk adverse" because they don't want
blemishes on their record and "perpetual war" as means of keeping
funds flowing ("risk adverse" and failing to adapt helps with
"perpetual war"); Success Of Failure culture is at the
organizational level as part of keeping the funds flowing ... avoiding
actually holding accountable those responsible

part of Boyd's "people first" can be ascribed to the the extensive
list of MICC high-priced failed technology efforts, frequently
obfuscated behind "there are always failures, when attempting
something new" (skimming enormous profits off of technology efforts
has been institutionalized in MICC).

from above:
This disconnects the entire decision process from reality, because
Orientation is the analytic/synthetic activity in the mind that makes
sense out of the Observations, including the feedback on a strike's
effectiveness. The disconnect of Observations from Reality allows
preconceptions and belief systems to hijack the synthetic function of
Orientation.

... snip ...

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

rreynolds@CIX.CO.UK (Rupert Reynolds) writes:
Does anyone have a copy of the old JARGON FILE that buzzed around the IBM
VM network in the '90s when i was working in Portsmouth North Harbour? I'd
love to see it again. I think it included discussion of Bubblegum vs.
Boeblingen.

i have few different versions done over the years ... but there are
also a few on the web.

in the early 80s, we modified the vm/rscs 6670 print driver (ibm copier3
with computer interface, distributed around departmental areas) to
randomly select "sayings" to help fill up the blanks on the separator
page (i.e. alternate paper drawer filled with colored paper). One of the
files of "sayings" was the ibmjargon file

Ran into problem with security auditors one year. I (and others) had
introduced a number of "demo" programs (aka *games* by any other name, I
brought in *adventure* inside ibm) and were maintaining growing large
library of demos. Corporate was having For Business Purposes Only
added to the vm370 logon screen ... and the security auditors claimed
that the demo programs had to all be removed since they weren't for
*business purposes*. It turns out we had gotten local change so that the
logon screen had For Management Approved Uses Only and had gotten
signoff on demo programs.

The security auditors were starting to feel like there was open conflict
with what they had been instructed from corporate. One evening as they
were doing after hours sweeps looking for unsecured classified material
... including classified prints-out left on 6670 departmental printers
... they came across print-out that had the following on the separator
page.
[Business Maxims:] Signs, real and imagined, which belong on the walls of the nation's offices:
1) Never Try to Teach a Pig to Sing; It Wastes Your Time and It Annoys the Pig.
2) Sometimes the Crowd IS Right.
3) Auditors Are the People Who Go in After the War Is Lost and Bayonet the Wounded.
4) To Err Is Human -- To Forgive Is Not Company Policy.

... and they attempted to escalate to top executives that we did it on
purpose ... attempting to ridicule them.

this is also about the time that I had first sponsored Col Boyd's
briefings at IBM. I first attempted to do it employee education and
they initially agreed. However, as I provided more information, they
changed their mind, suggesting I restrict the audience to just senior
members of competitive analysis departments. They explained that the
corporation spends a large amount of money training managers on how to
deal with employees, and they were afraid that exposing general
employees to Boyd would be counter productive.

The Price of Inequality: How Today's Divided Society Endangers Our
Future (Joseph E. Stiglitz) pg35/loc1169-73
In business school we teach students how to recognize, and create,
barriers to competition -- including barriers to entry -- that help
ensure that profits won't be eroded. Indeed, as we shall shortly see,
some of the most important innovations in business in the last three
decades have centered not on making the economy more efficient but on
how better to ensure monopoly power or how better to circumvent
government regulations intended to align social returns and private
rewards.

Freefall: America, Free Markets, and the Sinking of the World Economy
(Joseph E. Stiglitz) pg271/loc5101-4
Standard economic theory (the neoclassical model discussed earlier in
this chapter) has had little to say about innovation, even though most
of the increases in U.S. standards of living in the past hundred years
have come from technical progress.56 As I noted earlier, just as
"information" was outside the old models, so too was innovation

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

"execs" or "scripts"

Jennifer Murphy <JenMurphy@jm.invalid> writes:
I notice that most people call the Rexx routines "scripts". I come from
an old VM/CMS and MVS/TSO world where they were called "execs". I have
to admit that "scripts" kinda grates on my ears (eyes?) a bit.

open systems and terminal emulators have had command scripts and
terminal scripts.

some of the ctss people went to the science center on the 4th flr and
did virtual machines, cp67/cms (which later morphs into vm370/cms) and
bunch of other stuff ... other ctss people went to project mac on the
5th floor for multics.

mid-60s, the ctss "runoff" document formater was ported to CMS at the
science center and called script. then GML is invented at the science
center in 1969, support for GML tag processing was added to the script
command. the use of "script" for document formating then created
conflict later when script came into use for command & terminal
scripting.
https://en.wikipedia.org/wiki/SCRIPT_%28markup%29

as in above references ... CTSS inspired much in cp67/cms (and later
vm370/cms) as well as inspired much in MULTICS ... which then inspired
unix.

other trivia, a decade after GML was invented at the science center,
it morphs into international standard SGML. After another decade, it
morphs into HTML (at cern);
http://infomesh.net/html/history/early/

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

"execs" or "scripts"

LesK <5mre20@tampabay.rr.com> writes:
I agree with both of you. My background was VM/CMS also. Trouble is
that 'execs' comes from the CMS filetype EXEC, but Windows has a .exe
which is entirely different, being what we would think of as a MODULE,
so their can be some confusion.

I don't much like the use of 'script' when referring to Rexx code. To
me it implies a simplicity that isn't appropriate to Rexx ("The
HelpDesk person was following a script."). I simply call my code a
program' and leave it at that.

The Price of Inequality: How Today's Divided Society Endangers Our
Future (Joseph E. Stiglitz) pg35/loc1169-73
In business school we teach students how to recognize, and create,
barriers to competition -- including barriers to entry -- that help
ensure that profits won't be eroded. Indeed, as we shall shortly see,
some of the most important innovations in business in the last three
decades have centered not on making the economy more efficient but on
how better to ensure monopoly power or how better to circumvent
government regulations intended to align social returns and private
rewards.

we were tangentially involved in cal. state data breach notification
law. in depth consumer surveys that #1 issue was identity theft, in
large part fraudulent transactions as result of data breaches. nothing
seemed to be done about it and it was hoped that publicity from
notifications might motivate corrective actions. Major issue is
normally security measures are done for self-protection. the breaches
weren't a threat to the institutions but to their customers ... so
there was no motivation.

IBM had a competitive data protection circa 1980. It was suing a
company (that made compatible computer products) for several billion
over theft of proprietary information (next generation disk
design). Judge used the "swimming pool" attractive nuisance analogy;
nobody could be expected not to steal proprietary information that was
just sitting around; IBM had to demonstrate security proportional to
claimed value of the information (corporations had been using legal
system in lieu of security). The several billion dollar
information/documentation had to be available to large number of
people working on next generation disks ... but at the same time have
security equivalent to Fort Knox with nearly nobody allowed access.

"Competitive" came up when I was first scheduling Boyd's briefing at
IBM and tried to do it through the employee education
department. Initially they agreed, but as I provided more information,
they changed their mind and suggested that I limit the briefing to
only senior members of competitive analysis departments (those
divining what the competition is doing). Their explanation was that
the company spends a large amount of money on training managers in how
to handle employees and exposing general employees to Boyd's briefings
could be counter productive.

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

This Award Winning British Speed Boat May Be Iran's Fiercest Weapon Against The US Navy

Saw this in US auto industry C4 taskforce meetings 1990 ... they could
clearly articulate the issues with foreign competition and changes
needed to respond ... and they weren't able to do it. Nearly decade
earlier, there was call for 100% unearned profit tax on US auto
industry. Foreign import quotas were to reduce competition and
significantly increase profit which was to be used to completely
remake the industry. Instead they pocketed it and continued status
quo. Recent reports are they continue to find it difficult to change
status quo.

I saw something similar in IBM hdqtrs locations in 1991 (just before
going into the red in 1992), executives could clearly articulate
changes that were needed ... but go back a couple months later and no
changes. There were major disconnects between what they could say and
actually being able to change; vested interests, head-in-sand, etc

it also corresponds to the "three decades" mentioned in Stiglitz
reference about business schools (teaching processes to eliminate
change and freeze the status quo beginning to dominate). Other
cultural influences during the period interacting .... drop in SAT and
other scores for generations after baby-boomers ... references of the
rise of "cult of personality" (at the expense of character) ... rise
of MBAs and focus on quarterly nos. It is like once specific changes
occurred ... that it acted as incubator (or at least eliminated
counter force against potential that always existed) for a whole
series of other aspects of culture.

One could make a case that rigid, top-down, command&control has
analogies in potential for corruption under strong dictatorships
versus much more egalitarian culture (it can be more efficient for
specific short-term, point, familiar objectives but fails as long-term
viable paradigm under changing conditions). A number of books
regarding nation survive/fail corresponding to
eqalitarian/non-eqalitarian characteristics. Fiske (history lectures
from 1880s, my wife's father was awarded set for some distinction at
west point) makes a point that our current form of gov. was heavily
influenced by the Scottish settlers in the mid-atlantic states and
would have been quite different if the English settlers had prevailed.

Some amount of misdirection in the article ... possibly has to do with
what leaks into the popular press. We were tangentially involved in
the Cal. state data breach notification act (having been brought in to
help wordsmith electronic signature act and lots of the participants
were heavily involved in privacy issues). There were indepth customer
surveys that found #1 issue was identity theft, primarily kind
involving fraudulent financial transactions as result of data
breaches. Nothing was being done about the breaches (except lots of
efforts to keep them out of the press) and it was hoped that data
breach notifications would motivate corrective actions and
countermeasures. Part of the issue was that majority motivation for
security measures normally is self-protection. The institutions with
the breaches weren't at risk of the fraudulent transactions ... it was
their customers & clients (so they had little motivation).

I had worked with Jim Gray at research on the original relational DBMS
and other things. More recently (before he disappeared), he con'ed me
into interviewing for chief security architect in redmond. The
interview went on over a period of several weeks, but we were unable
to come to meeting of the minds. One of the things I pointed out was
that desktop computing had arose in the 80s with totally isolated,
unconnected box. Later, safe, local, small, business LAN connectivity
was added ... and a paradigm of including automatically executable
scripts in application data evolved. At the '96 spring MDC held at
Moscone, all the banners were about supporting the internet ... but
the theme in every session was about "protecting your investment" (aka
preserving the automatic scripting paradigm). I've periodically drawn
the analogy of just remapping the small, safe, local business LAN
support to the wild, anarchy of the internet ... to shoving somebody
out an airlock in open space w/o a spacesuit. A lot of the security
design of original desktop computing and what is needed for an
internet appliance are diametrically opposed.

in theory under SOX ... the executives (and their auditors) would be
doing jail time. More recently seen on the internet ENRON was dry run
and worked so well that it has become institutionalized.

If one believed all the rhetoric about SOX a decade ago, they would be
expecting thousands of executives and auditors currently doing jail
time.

Another indication that during last decade, SEC was playing three
monkeys (see no evil, hear no evil, speak no evil) came up in the
Madoff congressional hearings. They had the person that had tried
unsuccessfully for a decade to get SEC to do something about Madoff
... references was that SEC was finally forced to do something when
Madoff turned himself in (some conjecture that he was looking for
gov. protection for him and his family from some of the entities that
were defrauded). Part of his testimony was that tips (whistle-blowers)
turn up 13 times more fraud than audits ... and that SEC had no tip
hotline ... but did have a 1-800 number for corporations to complain
about audits.

Other decade old rhetoric regarding SOX was that possibly only the SOX
whistle-blower section would actually make any difference (not
expecting any benefit from audits) ... but that would have also
required that SEC actually do something.

"execs" or "scripts"

Jeremy Nicoll - news posts <jn.nntp.scrap007@wingsandbeaks.org.uk>
writes:
No. Script was the underlying language processor with the ability to parse
free format text and fundamental commands (the dot commands like .br) and it
allowed one to write macros (eg .this) combining multiple dot commands and
using logic to examine attributes of arguments to the macros.

GML was a start-set of macros written in the Script language, using its
builtin parser to associate a supplied set of macros with a supplied set of
tag names. So eg the script initialisation parms told the parser how in
general it should parse the user's text and in particular for each of the
supplied tag/macro combinations whether to apply simple or more complicated
parsing of tags and attributes.

Madnick doing runoff port from ctss to cms, as script in 1966 (at the
science center) ... predates the invention of GML (at the science
center) in 1969 (Madnick also having done the original CMS *exec*
processor).

support for GML *syntax* was original implemented as script macros
... in fact, it was possible to intermix "dot" (aka original
script/runoff) controls in same file with GML *tags*.

John.McKown@HEALTHMARKETS.COM (McKown, John) writes:
X64 hardware, as much as it has improved, is still not as reliable or
have the I/O capacity of the z hardware. E.g.: We had a TCM fail
once. A spare picked up the work, automatically restarting the
instruction stream, with no outage of any sort and no software
involvement. X86, from what I'm told, would at least require the OS to
do the equivalent of a checkpoint restart. Also had an OSA fail. The
other OSA did an ARP takeover and no IP sessions were lost. TCPIP was
informed, but all it did was put out a message and not start any new
sessions on the failing OSA. Our "open" people called me a liar when I
told them that.

big cloud operators do hundreds of thousands of blades in megadatacenter
with lots of failure/recovery infrastructure to handle individual blade
failures (usually with lots of power, telco, provisioning provisioning).

Gray had been studying mix of failures issues (both at IBM and later at
Tandem) and by '84 published report that hardware failures had become
minority of failure modes (hardware reliability had increased so other
kinds of failures were starting to dominating). scan of '84 presentation
http://www.garlic.com/~lynn/grayft84.pdf

several of the big cloud operators have published detailed studies of
different component availability as part of building their own blades
... given optimal service life per dollar.

Cluster & take-over were increasingly being used to mask all kinds of
outages ... even able to handle geographic operations and handling
disasters taking out whole datacenter.

when we were doing ha/cmp ... we did a lot of failure mode study ... and
part of our marketing was against hardware fault-tolerant systems. We
showed availability of ha/cmp clusters was higher than the
fault-tolerant systems. In competitive situation involving 1-800 number
server (i.e. maps 1-800 number to "real" number) ... it required
five-nines availability. hardware fault-tolerant system still required
scheduled system outage to do software upgrade ... which would blow
several decades of downtime budget. With cluster operation, we showed at
least as good hardware availability (with redundant systems) along with
capability of doing rolling software upgrades with no system outage.

the hardware fault tolerant vendor eventually came back with suggestion
that they could come out with redundant, cluster system operation ... to
handle the software upgrade issue. However, given reliability of
the underlying hardware operating in redundant, cluster system mode ...
there was no longer any justification for hardware fault tolerance.

part of ha/cmp was ip-address take-over ... which according to all the
standards should time-out mac/ip-address in arp caches. at the time,
most vendors were using BSD 4.3 tahoe or reno software for their tcp/ip
stacks. In 1989, we found a bug in the BSD4.3 tahoe/reno IP/ARP lookup
software. The ARP cache management was correctly timing out the ARP
cache entries (so if there was ip-address take-over, it would discover
the new MAC mapping). However, the BSD4.3 IP code had a performance
optimization where it saved the last ip/mac lookup results ... which
would only get reset if the client communicated with a different
ip-address (otherwise that saved ip/mac mapping would exist
forever). Since the "bug" existed in nearly every vendors implementation
(all using same BSD4.3 tahoe/reno software), we had to come up with a
work-around for the saved ip/mac bug. Any time there was ip-address
take-over, we would quickly saturate the local LAN with dummy traffic
from a different ip-address ... forcing all the machines on that LAN to
perform a real ARP cache lookup (resetting the "saved" value). Then the
next activity from the taken-over ip-address would force the clients to
do a real ARP cache lookup.

discusses Spanish conquest of the new world which was plunder and
enslave the local population (and keeping them at subsistance
level). This is compared with the English originally attempting to
emulate a similar strategy for Jamestown, almost starving the first
two years because they originally sent over skills oriented to
plundering and enslaving the local population ... then changed the
strategy to sending over enslaved English that had no rights, the
"leet-men", pg27:
The clauses of the Fundamental Constitutions laid out a rigid social
structure. At the bottom were the "leet-men," with clause 23 noting,
"All the children of leet-men shall be leet-men, and so to all
generations."

... snip ...

Boyd talks about this some in Organic Design For Command and Control
... one of his examples when he was command at spook base (NKP) and
his use of "legal eagle" and comptroller for independent communication
paths. Ends with leadership & appreciation (instead of
command&control) ... along with trust; odcc pg7:
Balck (1980)

Emphasis upon creation of implicit connections or bonds based upon
trust, not mistrust, that permit wide freedom for subordinates to
exercise imagination and initiative -- yet, harmonize within intent of
superior commanders. Benefit: internal simplicity that permits rapid
adaptability.

... snip ....

He would spend some time talking about Guderian's verbal orders
only during the blitzkrieg ... part of Guderian trust and
subordinates were encouraged to do the best possible at the time and
not worry about need for paper CYA afterwards.

... and warn about how US military rigid, top-down, command&control
was contaminating US corporate culture.

X86 server

John.McKown@HEALTHMARKETS.COM (McKown, John) writes:
"has always been" -> "had always been". As you indicated, at first
software was written in order to sell the hardware. It was basically
"overhead". However, when PCMs such as Amdahl came along and simply
started redistributing IBM software (which they got for free since
they owned IBM hardware), IBM had to have some other way to recoup
their costs. Also, they started unbundling when the courts found them
guilty of a monopoly which included their refusal to distribute
software to non-IBM customers. At least, as best as I can recall after
lo these many years.

23jun69 unbundling announcement was result of various litigation,
required starting to charge for application software, SE services,
hardware maint., etc. Company managed to make the case that kernel
software should still be free. misc. past unbundling posts
http://www.garlic.com/~lynn/submain.html#unbundle

FS effort in the early 70s was motivated by competition clone
controllers (it was going to have been radically different from 370),
The rise and fall of IBM
http://www.ecole.org/en/seances/CM07
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. But this proved to be difficult because
of IBM's cost structure and its R&D spending, and the strategy only
resulted in a partial narrowing of the price gap between IBM and its
rivals.

during Future System period, internal politics killed off and/or
suspended 370 acitivty ... also I continued to work on 360/370 stuff
... and periodically ridiculed FS (which possibly wasn't the greatest
career enhancing activity). The lack of 370 products was credited with
allowing clone processors to gain market foothold.

With the rise of the clone processors (made possible by the lack of
products during the FS period) and with effort to get stuff back into
the 370 product pipelines ... there was also a change in the decision to
start charging for kernel software. This was going to be a staged
conversion ... with new kernel add-ons being charged ... leaving base
software free ... at least during transition period. One of my pieces
selected to go out was my resource manager ... and it was selected as
the guinea pig for starting to charge for kernel software (initially
add-on pieces) and I got to spend some amount of time with business
people about kernel charging policies. misc. past posts mentioning
my resource manager and/or scheduling
http://www.garlic.com/~lynn/subtopic.html#fairshare

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

uriel.carrasquilla@MAIL.MCGILL.CA (Uriel Carrasquilla) writes:
When I used to work for the stock exchange (in Vancouver), it was
always the question about MF versus Tandem/Stratus fault-tolerant
equipment.
Yes, most of the problems were not hardware related.
But one time we were hit by a massive failure in the primary and
backup components that brought trading down. It is black swan but can
happen and the consequences can be nasty.
When it comes to our mission critical applications, we are still a
long way from going to the clouds.
But for those systems that we can afford the risk, yes, we will go to the cloud.

in ha/cmp we spent some amount of time with siac ... ran dataprocessing
for exchange ... they had a carefully selected datacenter in a building
that had lots of diverse routing ... two different water mains on
different sides of the building, different electrical mains on different
sides of the building to different substations, and four different telco
feeds on four sides of the building into four different central
exchanges (this besides UPS and power backup). past posts mentioning
ha/cmp
http://www.garlic.com/~lynn/subtopic.html#hacmp

I was then asked to write a section for the corporate continuous
availability strategy document ... but when both rochester and POK
complained that they couldn't meet the requirements ... my section got
pulled.

ibm has base price of $1815 for e5-2600 blade ... which have ratings at
527BIPS (about $3.44/BIPS), at $1815, $5B represents approx. 2,754,800
e5-2600 blades (2754800*527 or aggregate of 1,452,000TIPS). Even if you
inflate the base blade price by a factor of ten times, that reduces the
number of blades (you could get for $5B) to 275,480 with aggregate
processing power of 145,000TIPS

On the other hand the major cloud operators have claimed that they
manufacturer blades with optimal components for 1/3rd the cost of brand
name blades ... with a cloud megadatacenter typically containing several
hundred thousand blades.

In the early 1980s, IBM developed a dedicated publishing tool called
Information Structure Identification Language (ISIL) based on GML. ISIL
was used to generate much of IBM documentation for the IBM PC and other
products at this time. In the late 1980s, a commercial product called
BookMaster was developed, based mostly on ISIL.

During the early 1980s, Don Williams at IBM developed DWScript to use
the SCRIPT/VS on the IBM PC.[2] In 1986, he developed a PC version of
ISIL called DWISIL. These products were only used internally at IBM.

... snip ...

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

Morten Reistad <first@last.name> writes:
Yes, there are hardware reference manuals for the KA,KI,KS,KL etc, just
as Prime made for the 550,750,850 etc; but nothing like the "50-series
architecture guide" or the "360 Principles of Operations.". With the
former in hand you could make assemblies of components that never were
Prime products, but were still fully supported. Like a "650", with two
550's connected to do MP just like two 750's made an 850. Or hang a
second I/O cage on a 2550, making it a low-profile 9350.

And so on. On the IBM side the relevance was first on what weird
combinations of software and channel/cpu configurations you could
run.

by at least 1970 ... the architecture group moved the principles of
operation to cms script file ... it was actually the architecture "red
book" for the red 3-ring binder it was distributed it. the architecture
entries were bracketed and intermixed with the corresponding principles
of operation information. the architecture entries gave things like
justification, alternatives, engineering implementation notes,
unannounced items, etc. cms script command line option controlled
whether the full architecture redbook was formated or just the
principles of operation subset. at the start, the full redbook was about
twice the size of the POO/POP subset.

in the 370 case, it was giving all the different plant sites a common
objective to work to ... 115/125 in boeblingen, 135/145 in endicott, 155
in kingston, 165 in POK, etc

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

"execs" or "scripts"

LesK <5mre20@tampabay.rr.com> writes:
Back then I had a commercial version of SCRIPT for the TRS-80 and it
was great! My (then) wife used it for her home typing business. My
vague memory says Alan Tannenbaum was the author.

by at least 1970 ... the architecture group moved the principles of
operation to cms script file ... it was actually the architecture "red
book" for the red 3-ring binder it was distributed it. the architecture
entries were bracketed and intermixed with the corresponding principles
of operation information. the architecture entries gave things like
justification, alternatives, engineering implementation notes,
unannounced items, etc. cms script command line option controlled
whether the full architecture redbook was formated or just the
principles of operation subset. at the start, the full redbook was about
twice the size of the POO/POP subset.

in the 370 case, it was giving all the different plant sites a common
objective to work to ... 115/125 in boeblingen, 135/145 in endicott, 155
in kingston, 165 in POK, etc

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

X86 server

scott_j_ford@YAHOO.COM (Scott Ford) writes:
Just for my 2 cents worth, ran P390s in one environment attached to two T1s.
Attached to them we're 3800 laser printers and some 3274s we couldnt replace.
The mainframes were an hour plus away in NJ, and our printed output queued up to the P390s.
Everything worked like a champ. I am now on Z/Pdt z/os1.12 on a intel
i7', everything s good, but are also only doing development.

1980 STL is bursting at the seams and they are moving 300 people from
IMS group to off-site bldg. the group tries remote 3270 support and find
it intolerable. I get con'ed into writing HYPERChannel support for use
as channel extender ... allowing them to put local channel-attached 3270
controllers at the remote site. Runs over T1 channel on the *campus*
collins digital radio T3 microwave. They don't notice any change from
cms local 3270 controllers in STL (maintaining their subsecond response
... back when mvs/tso people were claiming noody needed subsecond
response). System thruput actually improves ... issue is the
HYPERChannel A220s sitting on real channel have significantly lower
channel busy (for the same operation) than 3270 controllers ... total
system throughput improves 10-15% (the 3270 controller channel busy is
masked at the remote site).

I try to get approval to release the software to customers ... which a
group in POK manages to block. That group was playing with some fiber
stuff (that eventually gets out as ESCON), and they are afraid if my
HYPERChannel support is released to customers ... it would interfer with
someday being able to get their fiber stuff out. As a result NSC has to
re-do my implementation from scratch.

Roll forward several years, the 3090 product administrator tracks me
down. the 3090 channels were designed to have 3-5 channel checks
annually aggregate across the whole customer base. the industry service
that collects erep data shows that there have been an aggregate of 20
channel checks the first year.

Turns out they are at customers running 3800 over HYERPChannel channel
extender. In my original implementation ... if I had an unrecoverable
transmission error ... I would simulate channel check in the CSW ... for
the host software to go through its retry operation ... and the NSC
faithfully reproduced that in their implementation. After some amount of
toiling through error recovery code ... i determined that simulating
IFCC would have effectively the same result as channel check and got NSC
to update their implementation.

as an aside, long ago and far away somebody in Boulder does build a
hardware channel emulator for ibm/pc which is used for 3800 testing.

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

"Joe Morris" <j.c.morris@verizon.net> writes:
Under VM/370 and its descendants, all program execution in a vm is performed
in problem mode (including execution in virtual supervisor mode), so
executing the DIAGNOSE opcode results in a privileged instruction trap; VM
uses this for its API between the virtual machine and the hypervisor. A
program designed to run both under VM and on a real machine could determine
if it is running in a VM by using an unprivileged instruction that returns,
among other things, the model number of the CPU: VM returned x'FF', which
meant that DIAGNOSE could be safely used.

after cp67 was installed at the univ., I started redoing large sections
... in large part oriented to general operation and running os/360
virtually. This is part of performance presentation that I made at
fall 1968 SHARE meeting about some of the changes:
http://www.garlic.com/~lynn/94.html#18

then i did some changes to cut (cp67) cms file i/o simulation pathlength
... doing it through standard SIO instruction ... but with a "special"
CCW op-code. I demonstrated significant cut in cp67 pathlenth for cms
file i/o. However, science center (Bob Adair) said that I had violated
principles of operation (i.e. 360/67 architecture ... since there was no
provision for doing such an implementation).

The suggestion was to implement such functions with the DIAGNOSE
instruction ... the principles of operation defines DIAGNOSE instruction
as having "model dependent" implementation. The fiction used was to
define a DIAGNOSE implementation that was for a virtual machine model.

the changes were shipped with cp67/cms ... with cms testing whether it
was running on real machine (and used standard SIO) or in virtual
machine (under cp67). for cms morph from cp67 to vm370, its name was
changed from "cambridge monitor system" to "converversational monitor
system" and the code for running stand-alone (and real hardware with
SIO) was removed.

after graduating and joining science center I then did cp67 interface to
support page-mapped filesystem. at the univ., the ibm people were still
periodically testing tss/360 ... and saw a lot of stuff "done wrong" in
its implementations ... and setout to avoid making the same mistakes.
This not only had more than the pathlength efficiencies that were done
for i/o simulation using diagnose ... but got a whole lot of
efficiencies because it aligned the cms filesystem operation with the
cp67 virtual memory and demand paged infrastructure (real I/O simulation
could still have a lot of stuff that worked at cross-purposes with the
paging infrastructure). misc. past posts mentioning memory mapped
filesystem
http://www.garlic.com/~lynn/submain.html#mmap

in the mean time, the future system effort took up "single-level-store"
... picking up a lot of stuff having been done in tss/360. it was one
area where I would ridicule what they were doing (believing what I
already had running was better than what they were blue skying about).
misc. past posts mentioning future system
http://www.garlic.com/~lynn/submain.html#futuresys

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

Peter Flass <Peter_Flass@Yahoo.com> writes:
IBM had to do that because the different models were designed by
different groups in the US, UK, and Europe. The POP was necessary to
keep everyone on the same page.

folklore/story, early 70s from somebody that relative at the
gov. antitrust litigation ... top executive from one of the 7 dwarfs
testified that in the late 50s every computer vendor realized that the
single most important customer issue was compatible product line
(computer uptake was starting to accelerate and computer upgrades was
becoming more common) ... and IBM executives (watson) were the only ones
that managed to enforce strict compatibility (aka individual product
managers wanting to optimize for their technology).

the corollary was being the only company getting the single most
important market/customer requirement *right* ... it was possible for
IBM to get many other things wrong ... and still come to dominate the
market (even if sometimes, the level of compatibility at application
level was just market perception).

Amdahl had left and was starting is own "clone" computer company. In
this period, he gave a talk in large MIT auditorium; during the talk a
student in the audience asked what justification did he use getting
investment. he said that even if IBM were to completely walk away from
370 (might be considered a vieled reference to FS), there already was
enormous customer investment in 370 application software development
that would keep him in business at least through the end of the century
(which has since come and gone).

the gov. litigation also motivated the 23jun1969 "unbundling"
announcement, starting to charge for application software, SE services,
hardware maintenance (howevere, the company managed to make the case
that kernel software should still be free). misc. past posts
mentioning unbundling
http://www.garlic.com/~lynn/submain.html#unbundle

Roll forward to the failure of the FS effort ... and there was mad rush
to get products back into the 370 pipelines (motivating decision to
release some of the 370 stuff that I had continued to do all thru the FS
period, I would also periodically ridicule what they were doing). With
the market foothold by the clone processors ... there was also a
decision to start charging for kernel software. One of the things I had
been doing (my resource manager) that was chosen for release, was
selected to be guinea pig for starting to charge for kernel software.
I got to spend a lot of time with business people disucssing pricing
politices for kernel software. misc. past posts mentioning my
resource manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

I mention that latest max configured z/196 with 80 processors is rated
at 50BIPS and goes for $28M ($560,000/BIPS). Also after Gerstner's
resurrection of IBM it shifted to services ... recently getting 83%
revenue from software&services ... and 17% from everything else
(including all hardware) ... hardware working out to about $5B each for
mainframe, i86, and power. At $28M, $5B total works out to equivalent of
180 max. configured z196 (or aggregate processing power of 180*50 =
9TIPS)

IBM has base price of $1815 for 35-2600 blade which have ratings of
527BIPS (about $3.44/BIPS), at $1815, $5B would represent 2,754,800
e5-2600 blades ... or aggregate processing power 1,452,000TIPS. Even if
you inflate the base blade price by a factor of ten times, that is still
275,480 blades and aggregate processing power of 145,000TIPS.

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

at hundreds of thousands blades in a megadatacenter and multiple
megadatacenters spread around the world ... they claim that they can
build their own for 1/3rd the price of brand name blades. they also have
done quite a bit of research into reliability of different commodity
components and buy in quantity for total cost of ownship. They also tend
to have some leverage over vendors that sell into the megadatacenter
server market.

with the enormous reduction in cost of hardware that they've been able
to achieve (if IBM has base price of $1815 for e5-2600 blade or
approx. $3.44/BIPS ... and megadatacenter may be able to achieve 1/3rd
that ... compared to $560,000/BIPS for z196) ... other costs start to
play an increasing role. The megadatacenters have also pioneered much of
the green datacenter efforts ... radically reducing power and cooling
costs ... establishing power&cooling cost measures per unit of computing
... somewhat analogous to the TPC council ... total cost per transaction
(gives results sorted by performance, price/performance and
watts/performance). A few recent posts mentioning mainframes
and TPC benchmarks:
http://www.garlic.com/~lynn/2012.html#23 21st Century Migrates Mainframe with Clerity
http://www.garlic.com/~lynn/2012h.html#20 Mainframes Warming Up to the Cloud
http://www.garlic.com/~lynn/2012i.html#16 Think You Know The Mainframe?
http://www.garlic.com/~lynn/2012i.html#89 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?
http://www.garlic.com/~lynn/2012j.html#1 Can anybody give me a clear idea about Cloud Computing in MAINFRAME ?

One of the issues is they have done significant excess provisioning for
"on-demand" requirements and so have pressured vendors for
implementations that drastically cut power use when idle ... but able to
instantaneously come up to full-speed.

They've also openly published their findings ... hoping to encourage the
component vendors to compete & improve their products. However, their
findings have also tended to influence blade component selection and
assembly by others.

X86 server

shmuel+gen@PATRIOT.NET (Shmuel Metz , Seymour J.) writes:
Only if you're talking about the same instruction mix. When one system
has instructions like MVCL and the other doesn't, MIPS truly means
"meaningless indication of processor speed". A comparison of FLOPS
ratings might be more meaningful, since the spread between the slowest
and the fastest operation isn't as large.

note that x86 BIPS ratings are number of iterations executing dhrystone
benchmark compared to vax 780 assumed to be 1mip ... have no idea *real*
instruction execution rate. past discussion in this thread
http://www.garlic.com/~lynn/2012d.html#41 Layer 8: NASA unplugs last mainframe

above also mentions i7-3960x is single socket/chip with approx. four
times the BIPS rating of 80processor z196

max. configured 64processor z10 was claimed to be 30BIPS ... and that
increased by 2/3rds to 50BIPS for 80processor z196.

increase in processors from 64 to 80 can account for increase of 25%.
tech articles claim the introduction of out-of-order execution for z196
accounts for another 20-25%. other misc. would then account for the
remainder of the increase.

note that out-of-order execution, branch prediction, speculative
execution, etc have all been part of risc technology for decades. the
recent generations of i86 processors have negated much of the risc
performance advantage by moving to risc processors with hardware layer
that translates i86 instructions to risc micro-ops.

part of the issue is that cache miss delays (aka access to memory)
counted in processor cycles are now compareable to 360-era disk access
delays. multiprogramming/multitasking was introduced to give processors
something to do while waiting for disk access. out-of-order execution
and hyperthreading are comparable for modern technologies (keeping the
processor units busy while waiting for stalled instruction access to
memory).

370/195 allowed out-of-order execution with pipeline ... but stalled at
conditional branch (having to wait to determine execution path that
branch would take). normal codes ran about half peak rate on 370/195
(because of branch stalls) and there was proposal to do simulated
multiprocessor (similar to modern hyperthread); two instruction streams,
pair of PSWs, two sets of registers ... etc. ... trying to maintain to
keep 370/195 running at peak processing rate.

modern branch prediction and speculative execution ... will do
out-of-order execution along one path (before branch condition is
determined). If the branch prediction is wrong, the incorrectly executed
instructions are undone ... and processing resumes along the correct
path.

there was reference to older mainframe TPC benchmark ... there was some
published work for z10 which was then prorated by 50/30 to give estimate
for z196 ... as a means of making other thruput comparisons.

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

cfmpublic@NS.SYMPATICO.CA (Clark Morris) writes:
Are there any benchmarks available comparing a z series against a
blade configuration doing the same work and comparing the cost per
benchmark unit? Given the complexity of instruction sets for both
Intel and the z series and the different nature of them, I agree with
others that straight instruction speed comparisons may be meaningless.
For example how much of the work for an i-o is done by the main
processor on a blade versus on the z series? What is the MP effect on
the blades versus the z series?

both refer to TPC benchmarks ... which have benchmarks that are RDBMS
transaction oriented with heavy disk i/o (as mentioned looking
at number of transactions/thruput, cost of transactions/thruput, and
power consumption of transactions/thruput)

Note that the e5-2600 blade is two socket-chip multiprocessor ... eight
cores (or processors) per chip for total of 16 processors (simulating 32
processor with hyperthreading) ... benchmark at 527BIPS (compared to
50BIPS for 80processor z196). e5-4600 blade are out there (four
sockets-chip multiprocessor, aggregate 32 processors, simulating 64
processors with hyperthreading) ... but having seen the dhrystone/bips
benchmarks ... but expecting over 1TIP for e5-4600. This post mentions
that mainframe sales of $5B last years translates into 180 $28m
max. configured z196 ... which at 50BIPS represents aggregate of 9TIPS.
http://www.garlic.com/~lynn/2012l.html#20 X86 server

Another part of the issue is that mainframe CKD disks haven't been
manufactured for decades ... CKD being an extra layer of simulation
(delay and overhead) on top of the same disks all the other platforms
are using.

a growing bottleneck for mainframe was the half-duplex channel
architecture requiring synchronized end-to-end operation on every
channel command and data transfer. the serialized i/o architecture that
started to appear in the late 80s had dedicated outbound and inbound
serial i/o data paths. The equivalent of a channel program was packaged
as data and transmitted down the outbound channel. This would be
followed by data-being written (on the same outbound channel as well as
other packetized channel programs) and asynchronously with data being
read flowing on the (dedicated) inbound channel.

Harrier was dual serial copper (out of Hursley from early 90s) ... that
packetized SCSI commands and operated at 80mbits/sec concurrent in both
directions. I mention here that I tried to evolved Harrier into
interoperate with fibre-channel ... old post discussing meeting in
Ellison's conference room early Jan1992
http://www.garlic.com/~lynn/95.html#13

from above:
When Fibre Channel started to compete for the mass storage market its
primary competitor was IBM's proprietary Serial Storage Architecture
(SSA) interface. Eventually the market chose Fibre Channel over SSA,
depriving IBM of control over the next generation of mid- to high-end
storage technology.

... snip ...

There were lots of discussion on the fibre channel standards mailing
list about pok/mainframe channel engineers trying to do unnatural acts
layering ficon ontop of the base fibre channel standard

I had been working off&on with LLNL on a number of things ... fibre
channel standard work comes from 1988 time-frame with LLNL looking to
standardized a serial technology they were using that had a non-blocking
switch for interconnect. This old email mentions doing benchmark on 4341
for LLNL ... LLNL were looking at getting 70 machines based on the
benchmark.
http://www.garlic.com/~lynn/2006y.html#email790220

customers looking at buying clusters of 4341 was a threat to POK
mainframes (somewhat the current situation of blade clusters and POK
mainframes) ... clusters of 4341 with greater aggregate processing and
thruput was much cheaper and had much smaller footprint of equivalent
POK mainframes. folklore is at one point, head of POK managed to have
allocation of a critical 4341 manufacturing component cut in half.
misc. old 43xx posts
http://www.garlic.com/~lynn/lhwemail.html#43xx

A big part of the myth around high mainframe i/o thruput comes from the
big increase in the number channels needed for 3090. The issue was that
from 3330 to 3380 disks, the transfer rate increased by factor of ten
... but the change from 3830 disk controller to 3880 disk controller
radically increased the channel busy time for operations (other than
pure transfer). The problem was that they went from 3830 fast horizontal
microprocessor to a 3880 slow vertical microprocessor. When the 3090
engineers found out how bad the 3880 channel busy was going to be they
realized they would have to drastically increase the number of channels
... in order to offset the drastically increased channel busy and to
achieve the desired throughput (which increased the number of TCMs,
which increased 3090 manufacturing costs; there were jokes that 3090 was
going to charge the 3880 group for the cost increase in 3090
manufacturing).

Note that the technology used in server blades can be significantly more
robust than what might be found in a desktop for a couple hundred
dollars (there periodic equating i/o capability of server blades with
what is typically found on entry desktop machines).

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

scott_j_ford@YAHOO.COM (Scott Ford) writes:
I saw the same exercise in a pharm. company trying to go from MVS,
multiple Lpars to unix. Several millions of $$$ and it was a
bust....some applications were difficult to convert

in the 90s, one of the biggest efforts was by the financial industry
(large concentration in manhatten) to move from overnight batch
window to straight-through processing ... using large
numbers of "killer micros" ... where several billions were dumped down
the drain. These efforts contributed to the "mainframe is dead"
stories from the period.

"real-time" transactions had been added to traditional batch ... but
the actual processing was still being down in the overnight batch
window. With globalization, there was combination of more work as
well as decreasing window size ... that was putting enormous pressure
on the paradigm.

billions were spent on parallized implementation using large numbers
"killer micros" implementing straight-through processing
... eliminated most of the work in the overnight batch
window. They used some parallelization technology with
roll-your-own implementations that looked good in the toy
demos. However, they failed to do the speeds&feeds and when it
came to production rollout ... the whole thing imploded horribly. The
parallelization technology being used introduced an increase in
overhead of 100 times (compared to cobol batch) ... totally swamping
any anticipated throughput increase from large number of "killer
micros"

I had done some simple speeds&feeds and pointed out the issue
before deployments but was ignored. I also got to work on improving
performance of cobol batch that ran everynight batch window on more
than 40 maxed out mainframes (40+ needed to handle workload,
datacenter took pride in saying no mainframe was older than 18months).

At least by the last half of the last decade, most of the major
non-mainframe RDBMS vendors (including IBM) had made significant
strides in non-mainframe RDBMS cluster-scaleup. I participated in
demonstration of straight-through processing implementations
that involved translating operations into fine-grain SQL operations
that would could be easily parallelized by latest generation of
non-mainframe RDBMS cluster implementations (more like factor of 3-5
times compared to cobol batch rather than 100 times). The financial
industry standards organizations were interested but there were lots
of comments there was still enormous resistance and risk aversion
because of the lingering effects of the 90s disastrous failures.

these large financial institutions continue to be major mainframe
customer market.

95/96 time-frame, consumer dailup online banking were making
presentations at industry conferences that they were moving to
internet ... a major motivation was consumer support costs associated
with serial-port dial-up modems (major support costs would effectively
be offloaded to ISPs). At the same time the commercial/cash-management
dialup online banking were saying they would *NEVER* move to the
internet (because of a long list of security reasons ... which have
since come to pass since they began moving to the internet).

Within the past couple years, the feds have been recommending that
businesses have a dedicated PC that is *NEVER* used for anything else
than online banking (as a partial return to the days of online
banking). This could be considered similar to the recommendation of
having a different browser that is dedicated to only being used for
online banking.

In the late 90s, there was lots of work being done on consumer
smartcards for authentication as countermeasure to stealing
credentials ... as well as the EU "FINREAD" standard as countermeasure
to compromised PCs. Then there was a large project in the early part
of this century with consumer smartcards and give-away of serial-port
cardreaders. The disastrous consumer support problems in the wake of
the give-away resulted in rapidly spreading opinion in the industry
that smartcards weren't practical in the consumer market (when the
problem was actually the give-way of serial-port readers;
demonstrating that all the institutional knowledge about serial-port
consumer support problems had evaporated in the span of a couple
years; note that serial-port issues were major motivation for
development of USB ... and the serial-port give-away cardreaders were
likely gotten in firesale on obsolete technology).

Within a year or two, there were some non-card "SAFE" payment products
developed (not as good as hardware tokens but better than what we have
now) which saw high acceptance between the e-merchants (accounting for
approx. 70% of online transactions of the period). However, merchants
had been indoctrinated for decades that interchange rate was
proportional to fraud rates ... and they were expecting order of
magnitude interchange rate reduction from the *SAFE* products. Then
the cognitive dissonance and the whole thing cratered when they were
told that instead of major reduction in interchange rates (for the
*SAFE* products), it would instead effectively be a surcharge on the
highest rate they were already paying.

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

Interesting News Article

"John F. Eldredge" <john@jfeldredge.com> writes:
That reminds me of living in a college dormitory. If anyone flushed a
toilet, the shower water would immediately become much hotter. The
custom was for anyone about to flush a toilet to call out a warning.
However, if the person flushing the toilet was on a different floor than
the person showering, you didn't get any warning.

berkeley folklore about cdc 6600 having thermal shutdown some time every
week ... loss of cooling in the machine room. eventually they determined
that it was morning class break at the same time lawn sprinklers were
going ... combination of all the toilets flushing and the sprinklers
dropped water pressure to datacenter cooling.

John.McKown@HEALTHMARKETS.COM (McKown, John) writes:
CA-7 has a similar function to run "cross platform" work. It requires
a "daemon" be running on the remote side. <WARNING type="plug">I like
Co:Z Launcher from Dovetailed Technologies to do this. It only
requires a standard SSH server on the remote end. And I can afford it
(it is zero cost.) </WARNING>

part of the issue is the MVS evolved from a paradigm where people
submitted card decks and the actual execution occured at much later
period ... with at most an operator present ... the responsible person
was no where around. the unix & desktop platforms evolved from the exact
opposite paradigm ... the computer was directly interacting with the
person executing the application. those platforms have had to do quite a
bit of evolution to handle server&unattended operation.

from above:
It ran for three hours on the night of March 30, at a cost of $4,828.85
per hour. Getting up to 51,132 cores required spinning up 6,742 Amazon
EC2 instances running CentOS Linux. This virtual supercomputer spanned
the globe, tapping data centers in four continents and every available
Amazon region, from Tokyo, Singapore, and Sao Paolo, to Ireland,
Virginia, Oregon, and California. As impressive as it sounds, such a
cluster can be spun up by anyone with the proper expertise, without
talking to a single employee of Amazon.

... snip ...

Not sure what an EC2 instance is made of for this (&/or if they are all
the same), an e5-2600 would have 16 cores and 6742 instances would be
aggregate of 107,872 cores (aka processors).

from above:
The size of effective addresses is controlled by bits 31 and 32 of the
PSW, the extended-addressing-mode bit and the basic-addressing-mode bit,
respectively. When bits 31 and 32 are both zero, the CPU is in the
24-bit addressing mode, and 24-bit operand and instruction effective
addresses are specified. When bit 31 is zero and bit 32 is one, the CPU
is in the 31-bit addressing mode, and 31-bit operand and instruction
effective addresses are specified. When bits 31 and 32 are both one, the
CPU is in the 64-bit addressing mode, and 64-bit operand and instruction
effective addresses are specified (see "Address Generation" in topic
5.2).

... snip ...

as an aside, 360/67 supported 24-bit and 32-bit addressing modes.

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

Findlay William <yaldnif.w@blueyonder.co.uk> writes:
They bought the paging patents that originated with the Ferranti Atlas, from
the UK NRDC to which they had been assigned (IIRC). The 370 VM (not VM/370)
ads did not actually claim that IBM invented paging, but they strongly
implied it. They were the cause of much hilarity in the UK.

{NRDC = National Research Development Corporation, a quango}

there was ibm system journel article stating something to that effect,
one of the co-workers from the science center wrote a letter to the
system journel editor pointing out all the mis-statements ... citing
sources (and suggesting that they should print correction). he got back
a letter from the editor effectively saying that it wasn't in the best
interest of the company to print a correction.

one the other hand ... melinda's vm370 history cites in mid-60s, some of
the early science center people saying that atlas paging had problems
and nobody in the company knew why ... aka this was leading up to
science center wanting the official corporate virtual memory charter
... and it went to tss/360 instead (and nobody at tss/360 knew what were
the problems with atlas paging).

from melinda's history (from past discussions problems may have been
related to lack of page thrashing controls):
What was most significant was that the commitment to virtual memory was
backed with no successful experience. A system of that period that had
implemented virtual memory was the Ferranti Atlas computer, and that was
known not to be working well. What was frightening is that nobody who
was setting this virtual memory direction at IBM knew why Atlas didn't
work.

... snip ...

this was before the ACM paper in '68 about working set dispatcher that
included page thrashing controls ... based on "local" LRU page
replacement. As an undergraduate in '68 I had done a form of page
thrashing controls with a clock-like global LRU replacement for cp67
(which I believed much more efficient than the ACM '68 working set
dispatcher)

roll forward to early '80s, somebody (co-worker of Jim Gray at Tandem)
was working on stanford PHD on "clock" and global LRU
replacement ... and the awarding of the PHD was being strongly
opposed/fought by the "local LRU" replacement forces. Jim was aware of
the work I had done as undergraduate and at SIGOPS (asilomor
14-16dec81) asks me to weigh in on the argument ... past post
http://www.garlic.com/~lynn/2006w.html#46

The Grenoble science center in the early 70s had modified their cp/67 to
correspond with the '68 ACM working set dispatcher, published results in
CACM ... and had also shared a lot of raw data with me. Basically, the
Grenoble cp67 working set dispatcher with 1mbyte 360/67 (155 4k pages
after fixed storage requirements) and 35 users got approx. same level of
performance as the Cambridge wheeler cp67 with 768k 360/67 (104 4k pages
after fixed storage requirements) and 75-80users (my stuff on machine
with 1/3rd less paging space and twice the users could perform as well
as grenoble working set dispatcher).

unfortunately it took me nearly year to get company approval to send a
response ... hopefully it was because they thought they were punishing
me for one thing or another (and not because research was trying to
weigh in on the other side of the "academic" dispute):
http://www.garlic.com/~lynn/2006w.html#email821019

Professor Dai Edwards (one of the designers of the Atlas) talks about the
paging ("one-level store") patents. He says nothing whatever to suggest
that paging on Atlas "did not work", or "had problems".

I have a slight suspicion that this may be a self-aggrandizing IBM myth.

discussion from last year ... it wasn't a page thrashing control issue
and/or global/lru issue since there was no concurrent execution
... atlas completely swapped address space pages on task switch
http://www.garlic.com/~lynn/2011e.html#2 Multiple Virtual Memory

from above post:
http://www.ics.uci.edu/~bic/courses/JaverOS/ch8.pdf

from above:
Paging can be credited to the designers of the ATLAS computer, who
employed an associative memory for the address mapping [Kilburn, et al.,
1962]. For the ATLAS computer, |w| = 9 (resulting in 512 words per
page), |p| = 11 (resulting in 2024 pages), and f = 5 (resulting in 32
page frames). Thus a 220-word virtual memory was provided for a 214-
word machine. But the original ATLAS operating system employed paging
solely as a means of implementing a large virtual memory;
multiprogramming of user processes was not attempted initially, and thus
no process id's had to be recorded in the associative memory. The search
for a match was performed only on the page number p.

... snip ...

The science center initial CP40 implementation was adding associative
virtual memory hardware to 360/40. A difference between the Atlas
hardware implementation and the implementation for 360/40 was that the
360/40 implementation included a process identifier.

The implication from above could be that ATLAS totally swapped all
virtual pages anytime it switched users/virtual-address space ... not
attempting concurrent users/tasks. Such a implementation would also
not need dynamic limit on concurrent executing tasks as page thrashing
control (aka some form of working set control). If it did LRU
replacement, there would be no difference between local & global.

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

John.McKown@HEALTHMARKETS.COM (McKown, John) writes:
Why am I getting a vision of Medusa? Or perhaps a sea anemone?
Tentacles reaching out to entrap prey. Pity the small servers in the
room, getting lashed with FICON cables. <GRIN>

IBM 1991 (power) cluster scaleup with fiber-channel (FICON is layered
on top of base fiber-channel standard) was in fact code-named
MEDUSA ... old email (fiber-channel was common use in
non-mainframe long before FICON):
http://www.garlic.com/~lynn/lhwemail.html#medusa

mainframe DB2 were complaining that if I was allowed to continue, it
would be a minimum of five years (if not decades) ahead of them. the
issue was this predated IBM's non-mainframe DB2 products, so had to go
to other vendors to get RDBMS on IBM's non-mainframes. These vendors
tended to have relatively common source base for both their
vax-cluster and unix platforms ... so the issue was to adapt their
vax-cluster support to unix platform and scale it up.

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
I believe the 370/165 was another. Well, that is a 370 not a 360,
but still. (And a 370 without virtual storage.)

all 370s were retrofitted virtual memory ... extra cost item for 370/155
and 370/165. there was major problems with retrofitting virtual memory
hardware to 370/165 ... which was going to result in (at least) six
month schedule slip in the announce of 370 virtual memory. Eventually it
was escalated and the decision was to drop a bunch of 370 virtual memory
stuff (that 165 was having trouble with) to keep things on schedule. the
problem became that all the other 370 models had to go back and remove
the dropped features from their implementations ... also any software
already written to use the drop features had to be reworked.

vm370/cms biggest hit was the dropping of 370 virtual memory segment
r/o protect. morph from cp67/cms to vm370/cms was to reorg cms so that
it could have shared read-only 370 "64k-byte segments" ... and use r/o
segment protect to prevent changes propagating across virtual address
spaces. vm370 then had to fall-back to a really ugly hack manipulating
storage protect keys and protect key in the psw.

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

EC12 announcement estimates it has 30% increase in DBMS thruput
(compared to z196)

old report estimated 5m tpmC for max configured z10 which could give a
guestimate of 7.5m tpmC for max configured z196 ... and at 30% increase
would give guestimate of 9.74m tpmC for max configured EC12. that could
put EC12 just below number two in the current tpmC rankings ... but
presumably an enormous way off in terms of price/tpmC.

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

the big cloud operators are doing mega-datacenters ... with extensive
RAS involving millions of processor ... and an individual
mega-datacenter has more computing power than the aggregate of all
mainframes in the world today with something like 100,000 times better
price/performance

With hundreds of thousands of blades and millions of processors
... the large cloud operators have been pioneers in all sorts of
things ... they pioneered evaluation of optimal price/performance,
reliability commodity components and openly publish results with
claims that they assemble their own blades at 1/3rd the cost of brand
name blades. With radical reduction in cost of dataprocessing
components they've pioneered people/computing power/computing,
cooling/computing, green datacenter techniques ... again openly
publishing the results (aka with radical reduction in the cost of the
dataprocessing components, other aspects become larger part of total
cost of ownership).

They've done a lot of work on optimally selecting locations for
building new megadatacenters ... sometimes in remote locations
... selecting for power availability, water/cooling availability,
year-round temperature & humidity (for cooling costs), etc. Public
announcements of deals with local governments for new megadatacenters
usually mention well under 1000 jobs (aka people-staff) for all
aspects of operating, maintaining, running such a megadatacenter (for
operation with more dataprocessing power than the aggregate of all
mainframes in the world today).

Part of the large cloud operations are large-scale, instantaneous,
on-demand ... and so they have done a lot of work with component
vendors on dropping power (& cooling) to zero when component is idle
... but able to come online nearly instantaneously.

Part of openly publishing the findings and evaluations is to encourage
the component vendors to improve their products (even if it may
provide competitive advantage to other large cloud vendors). The
megadatacenters have evaluations for total cost of operation
(including optimal "green") ... similar to what TPC & SPEC council do
for individual types of benchmarking (where in addition to having
rankings based on aggregate throughput, they also have rankings based
on cost/operation and power/operation).
http://www.tpc.org/ .
http://www.spec.org/

IBM has base list price of $1815 for e5-2600 blade. There are various
processor configurations for e5-2600 (two socket-chip,
8processors/socket-chip, 16processors) ... but some are benchmarked at
527BIPS ... using IBM base price, $113.44/processor, $3.44/BIPS,
33BIPS/processor. Large cloud operator claims of being able to
assemble blades at 1/3rd cost of brand name blades potentially has it
down to $1.14/BIPS.

from above:
As impressive as it sounds, such a cluster can be spun up by anyone
with the proper expertise, without talking to a single employee of
Amazon.

... snip ...

Note assume the EC2 instances "spun" up are all e5-2600 ... then that
would be an aggregate of 1,687,356 BIPS or the equivalent of 2,704,096
(z196) processors (at 625MIPS/processor) ... or approx. 33,801
(max. configured) 80 processor z196 machines ... at price of $28M each
... would come out to approx. trillion dollars. IBM statements are
that it has been doing approx. $5B/year in mainframe business ... that
would translate into approx. 180 (max. configured 80 processor) z196
per year. 33,801 z196 machines at a rate of 180/year would represent
approx. 188yrs of z196 sales ... just for the equivalent of the
example on-demand supercomputer (carved from an available subset of
the amazon cloud).

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

First Battle: Operation Starlite and the Beginning of the Blood Debt
in Vietnam (Otto Lehrack) pg165|loc2900-2904
Perhaps the most important reason for the so-so result was that the
Viet Cong had gained an enormous appreciation of the Marines' ability
to project power from the sea as a result of Starlite. Never again in
the course of the war did they permit their units to tarry on the
coastal plain. When they had a job to do near the water, they came in
and did it, and then they fled inland again. Although they developed
good antiaircraft techniques and weaponry during the war they had
neither the ordnance nor the expertise to thwart an amphibious landing
force.

... snip ...

so one of the lessons for the Chinese is countermeasures for
amphibious operation. Another point in the book was Westermoreland
Army background regarding large 2nd generation encounters (tank
slug-fests in Europe) pg167/loc2924-27:
Ironically, Starlite, a Marine victory, reinforced General
Westmoreland's notion that carrying the fight to main force enemy
units was the key to success in Vietnam. This belief helped keep
pacification, the Marines' focal point, in a secondary role.

One of Boyd's biographies mentioned he did tour commanding spook base;
his Organic Design for Command and Control makes an oblique reference
to NKP (pg.28: My use of "legal eagle" and comptroller at NKP). He
would claim that early on he said it wouldn't work so the assignment
may have been punishment. NKP description (gone 404, but lives on at
wayback machine):
http://web.archive.org/web/20030212092342/http://home.att.net/~c.jeppeson/igloo_white.html

Boyd in his briefings would describe how the US military resorted to a
rigid, top-down, command&control for WW2 in order to deploy huge
numbers with little or no experience and leverage the few skilled
resources available (assuming that only those at the very top knew
what they were doing). He would contrast US military with 11% officers
(growing to 20% needed to maintain rigid, top-down, command&control)
with German 3% officers He would then describe that by the early 80s,
that many of those officers had returned to civilian life and were
starting to contaminate US corporate culture with similar rigid,
top-down, command&control infrastructure. The downside was it made
organizations much less agile and adaptable and created barriers to
being able to use skills that existed at other levels of the
organization (with the implied assumption that only those at very top
knew what they were doing).

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

both articles cite what amazon charges for on-demand use of the
instances ... including what it is required to make a profit, cover
all costs, cover the costs of having significant excess provisioning
with idle capacity to meet instantaneous on-demand. While I mentioned
those additional cost for the amazon operations ... I didn't bother to
go into additional details since there are no equivalent
total-cost-of-ownership for an equivalent mainframe-based cloud. The
articles also say that the price for prescheduled, planned is lower
... since it significantly reduces the cost of providing for idle
provisioning that allows for instantaneous on-demand.

as repeated for above, $4829/hr for 51,132 cores ... which works out
to $42,302,040/yr (24*365) to cover *ALL* amazon costs plus profit
including having lots of idle computing laying around for "on-demand"
requirements. That $42m/yr is for the equivalent processing power of
33,801 maxed out z196 computing systems at nearly $1T ... for less
than the price of two Z196 ($56M).

On-demand provision for the equivalent of having 33,801 idle z196
(@$28M) sitting around as part of large cloud service ... possibly
requires operation with 100,000 total aggregate z196. Is there a
total-cost-of-ownship for 100,000 z196 machines plus purchase price
(probably closer to 500,000 z196 machines) ... plus profit margin to
provide an equivalent level of on-demand service (where the base
purchase price is already going to be several trillion dollars). What
is the physical planning, power requirements and cooling for 100,000
z196 machines?

I remember getting into lots of fights with the communication group
over token-ring versus ethernet. They had published a report comparing
16mbit token-ring with ethernet. They only way that the numbers made
sense was if they had used the original experimental, prototype, 3mbit
ethernet that predated listen-before-transmit instead of product
10mbit ethernet (aka the comparison was enormously skewed and
biased). Almaden research had just been built and provisioned with
lots of cat5 for 16mbit token ring ... but they quickly moved to cat5
ethernet because it provided actual higher lan thruput capacity and
lower latency than 16mbit token-ring (example of how skewed the
numbers can be).

Original virtual machines was done at the science center in the 60s
with cp67 (actual first one with cp40 on specially modified 360/40
with virtual memory hardware) . Several online commercial service
bureaus sprung up in the 60s offering online ("on-demand")
service. Several enhancements to cp67 had to be done to get its use
for 24*7 service bureau operation. Initially off-shift use was very
light but to develop 24*7 use ... the systems had to be left up all
the time. In order to afford leaving the systems up all the time, the
off-shift costs had to be enormously reduced (because of initially
little or no 7x24 use).

At the time, IBM leased machines and charges were based on the "system
meter" that ran whenever the processor and/or channels were busy. A
hack had to be done to cp67 to allow the system meter to stop when
nothing was going on ... but still leave active channel programs that
would accept incoming connections/characters from dialed-in users. The
system meter also would only come to a stop when both processor and
all channels had been idle for 400ms. Note that at least well into the
late 70s (long after switch-over from lease to sales, and for all I
know continues today) MVS had a special system function that would
wakeup every 400ms (to make sure that the system meter never stopped).

To reduce the operational costs of cp67 (especially 7x24, off-shift,
when load was nearly non-existent) lots of enhancements were required
for dark-room, operator-less operations. One of the things was after a
system crash, it would automatically re-ipl and restart to operational
state w/o manual/operator intervention.

Also in the 60s, service bureaus enhanced cp67 for loosely-coupled,
single-system-image operation. Part of the issue is that hardware
maintenance in the 60s required taking systems down/offline. To make
this transparent to the users ... transparent process migration was
added ... that it was transparent to users which systems they ran on
... and running users could be transparently moved between systems w/o
interruption ... allowing systems to be taken offline for (both
hardware & software) maintenance and service.

For various reasons, many of these features from the 60s commercial
virtual machine operation never made it into the cp67 products &/or
subsequent vm products. Last I looked, the z/VM cluster support still
didn't provide for transparent process migration between systems in
cluster operation.

One of the largest virtual machine single-system image, cluster
operations was the internal HONE system providing world-wide
sales&marketing support (thru the 70s & much of the 80s). While it had
transparent system operation in the cluster, connect load-balancing,
and automatic re-connect ... it never did do the transparent process
migration that originated in the 60s with some of the virtual machine
service bureaus.

Just seen on the internet: "IBM mainframe computer sales are 4% of
IBM's revenue; with software, services, and storage it's 25%". This
implies for every million in mainframe hardware sales, IBM charges
$5.25m in software, services and storage ... i.e. a trillion dollars
in z196 sales (for the 33,801 z196 machines), total cost from IBM
would be closer $6.25trillion (which doesn't include building,
cooling, staff, power, etc).

As to business continuity ... when I was doing HA/CMP ... I was asked
to do a section of the corporate continuous availability strategy
document ... however it got pulled because both Rochester and POK
complained that they couldn't meet the requirements.
http://www.garlic.com/~lynn/submain.html#available

As to PCI-DSS there are various references it was an industry
specification to help support federal legislation to eliminate data
breach notification (aka the definition of PCI-DSS certification
is never having a data breach, PCI-DSS certified institutions
that have a breach, have their PCI-DSS certification revoked). 1995, I
was asked to participate in the financial industry standard x9a10
working group that had been given the requirement to preserve the
integrity of the financial industry for *ALL* retail payments. As
part of that effort, we did extensive, detailed, end-to-end threat and
vulnerability studies of the major kinds of retail payments. PCI-DSS
only has very small coverage of the threats and vulnerabilities. We
were then involved with the entities doing the cal. state data
breach notification legislation (original in the country). Note X9
is chair for the (international) ISO financial standards group ... so
X9 standards tend to proceed to ISO standardization. I was also the
co-author of the financial industry privacy standard, X9.99 that then
became ISO standard.

In the 90s, the financial industry spent billions of dollars to move
mainframe overnight batch to large number of parallel killer micros
(the efforts were behind lots of the comments about death of the
mainframe). the issue was that while online, real-time transactions
had been added to mainframe financial applications ... the transaction
didn't go to settle until the overnight batch. The issue in the 90s
was that globalization was increasing the workload needed to be done
and also decreasing the size of the overnight batch window. The
objective was to re-implement the whole infrastructure as
straight-through processing on large numbers of parallel killer
micros. The problem was that they were using some parallelizing
technology and never did the speeds&feeds ... things looked great
in toy demos ... but the technology introduced factor of 100times
overhead ... totally swamping any improved thruput benefits of the
killer micros (compared to cobol batch). The resulting disasters when
moved into production created enormous fear and risk aversion in the
industry. I had done the speeds&amplfeeds beforehand ... but nobody
wanted to listen. I then got brought in to do 14% improvement on
overnight cobol batch application that ran every night on over 40
maxed out mainframes.

Since then most of the non-mainframe RDBMS vendors (including IBM)
have done an enormous amount of throughput and performance work for
(non-mainframe) RDBMS cluster scaleup. A couple years ago, I was
involved in taking a straight-through implementation based on
non-mainframe parallel RDBMS ... that met all of the financial
industry objectives (enormous increase in performance thruput
headroom, enormously lower cost, ACID properties, RAS, continuous
operation) to industry associations. The technologists were highly
favorable ... but eventually the people running the associations said
that at the executive level, there was still lingering effects and
risk aversion from the 90s disasters ... and things would have to wait
for new generation.

It is at $48M/annum that has everything ... including building, staff,
taxes, profit, cooling, power ... compared to $6.25T that doesn't
including building, staff, taxes, profit, cooling, power, etc.

I would assert that anything deemed deficient in the $48M/annum could
be added for less than the cost of the missing equivalent mainframe
items (building, staff, taxes, profit, cooling, power, etc) ... still
leaving a $6.25T gap (also 6.25T/48M = 130,208).

It would be possible to replicate the $48M/annum ... 100 times ... and
still not make a noticeable dent in the $6.25T required for equivalent
mainframe.

33,801 z196 @31.7kW is then 1,071,491kw or 1,071MW not counting power
for cooling, disks and other peripherals. This has 18.7kW for DS8800
http://www-03.ibm.com/systems/at/resources/systems_at_webkonferenzen_ibm_ds8800.pdf

at one DS8800 per z196, that would bring it up to 50.4kW and for
33,801 systems would be 1703570kW or 1704MW.

Even at 5cents per kwh, just electrical bill would be $85,179/hr
compared to $4829/hr for fully loaded price for on-demand
supercomputer subset of Amazon cloud.

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

Recent from the democratic side in congress ... implies that efforts
stretched out for much longer that they actually seemed to. loc860-65:
At the December 2009 hearing, the three witnesses -- Breuer, Khuzami, and
Perkins -- said all the right things. Don't worry. We're on the
case. These are complex financial frauds committed by sophisticated
actors. It takes time and patience to develop these cases. We're
reviewing the facts and the evidence. We'll bring criminal or civil
actions where the facts take us. Stay tuned. At the time, we believed
them. Unraveling sophisticated financial fraud is an enormously
complicated and resource-intensive undertaking, because of the nature
of both the conduct and the perpetrators.

... snip ...

Note: Jan. 2009 I was asked to HTML'ize the Pecora hearings (30s
senate hearings into '29 crash, had been scanned at boston public
library fall of 2008) with lots of internal xrefs and lots URLs
between what happened this time and what happened then (some
anticipation that new congress would have appitite to do something). I
worked on it for some time, but well before summer of 2009, I got a
call that it wouldn't be needed after all (references to enormous
piles of wallstreet money being spread around capital hill).

characterizes that it was actually over before it ever started, that
the economic A-team helped get the president elected but they were
going to choose the "swedish" solution (over the lingering "japan"
solution) and hold those responsible on wallstreet accountable.
Instead the president appoints the B-team, people that were involved
in creating the economic mess and not likely to hold anybody
accountable.

from above:
In 1995, the Big Six -- JPMorgan, Bank of America Corp., Citigroup
Inc., Wells Fargo & Co., Goldman Sachs Group Inc. and Morgan Stanley
-- had assets worth only 17 percent of U.S. gross domestic product. As
recently as 2005, their collective balance sheets were valued at less
than 50 percent of GDP.

Today, the Big Six are much bigger, with combined assets of 60 percent
of GDP.

Bailout pg157/loc3106-9:
HAMP was not separate from the bank bailouts; it was an essential part
of them. From that perspective, it didn't matter if the modifications
failed after a year or so of trial payments or if struggling borrowers
placed into doomed trial modifications ended up far worse off, as long
as the banks were able to stretch out their pain until their profits
returned.

Too true to be funny - 51% of the surveyed Americans think that stormy we

Efinnell15@AOL.COM (Ed Finnell) writes:
There was a 'dark comedy' film in the sixties, maybe Marcel Marceau where
the Inmates were running the town at the end of WWII-dodging the various
military factions, keeping the peace, and providing for the general welfare.
The comedy I suppose is they were doing a better job than the previous
administration.

It was cult film still playing non-stop down at central square (theater
at the fork/junction of main & mass av) ... somewhat characterized as
inmates being in charge of the institution.

i was at the science center at tech sq (couple blocks down main st) and
continued to work on 360/370 ... all during the Future System period
... which was going to completely replace 370 with something totally
different ... and internal politics was killing/suspending 370 stuff. I
would periodically ridicule the FS activity ... including drawing
analogies with the cult film (inmates being in charge of the
institution) ... not the most career enhancing comments. misc. past
posts mentioning science center at 545 tech sq
http://www.garlic.com/~lynn/subtopic.html#545tech

the lack of 370 products during the FS period is credited with
giving the clone processors market foothold.

For the fun of it ... "School of Sun Tzu" citing Chet; loc.3073-79:
Dr. Chester W. Richards developed a war "paradigm" that blends the
mental and the physical. He thanks the late US Air Force colonel, John
Boyd, "of the Sun Tzu school, and by far the most influential
strategist of our generation," for his help in establishing a "modern
paradigm for winning in armed conflict by destroying morale with quick
and painless tactics." The paradigm he calls "rapid OODA speed" was
applied with success, he says, in the Gulf War. Richards summarizes
Ping-fa as "an uncompromised indictment of generals whose only ideas
of strategy are frontal assaults and battles of attrition."

IBM has base list price of $1815 for e5-2600 blade. There are various
processor configurations for e5-2600 (two socket-chip,
8processors/socket-chip, 16processors) ... but some are benchmarked at
527BIPS ... using IBM base price, $113.44/processor, $3.44/BIPS,
33BIPS/processor. Large cloud operator claims of being able to
assemble blades at 1/3rd cost of brand name blades potentially has it
down to $1.14/BIPS.

with number of z196s for equivalent BIPS aka 33,801 z196 80 processor
machines. the $4829/hr works out to $48M/annum ... less than the $56M
cost of two z196s. The cost of 33,801 z196 comes out to around
trillion dollars. From yesterday, analysis that IBM sells $5.25M in
mainframe software, services and storage for every million in
mainframe sales ... making cost of 33,801 z196 closer to $6.25trillion
(with software, services, and storage) ... doesn't include building,
staff, power, cooling, taxes, etc (which would be included in an
amazon cloud costs).

33,801 z196 @31.7kW is then 1,071,491kw or 1,071MW not counting power
for cooling, disks and other peripherals. This has 18.7kW for DS8800
http://www-03.ibm.com/systems/at/resources/systems_at_webkonferenzen_ibm_ds8800.pdf

at one DS8800 per z196, that would bring it up to 50.4kW and for 33,801
systems would be 1703570kW or 1704MW.

Even at 5cents per kwh, just electrical bill would be $85,179/hr
compared to $4829/hr for fully loaded price for the on-demand
supercomputer subset of Amazon cloud.

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

The question upthread wasn't about putting PII into the cloud ... but
the total costs of open systems (one source being cloud prices for
their open systems) compared to total mainframe costs. What a cloud
operator charges for their open system use should be approx. of actual
total costs (plus some uplift for profit operation). The analysis from
yesterday for total mainframe price was that IBM charges over six
times the hardware cost for total mainframe (i.e. earns total of
$6.25million from every $1million of mainframe hardware) ... but
doesn't include total cost to customer including building, power,
cooling, staff, etc.

Two of the people mentioned, later leave and show up at small
client/server startup. We then get brought in as consultants because
they want to do payment transactions on their server; the startup had
also invented this technology call "SSL" they want to use, the result
is now frequently called "electronic commerce".

As part of the effort, we do analysis of SSL, browser, and digital
certificate operations and come up with several requirements for
secure operation. After deployment, many of the requirements are
almost immediately violated and we start referring to it as "comfort"
security (only provides comfort with the appearance of security).

We document that business processes in payment infrastructure are
severely mis-aligned ... independent of whether it is open system,
mainframe, cloud, etc. For one; the typical profit a merchant receives
from electronic transaction can be a few dollars (and a few cents for
a transaction processor). In contrast, the value of the same
transaction information to the crooks is the account credit limit or
balance. As a result, crooks can frequent afford to spend 100 times
attacking the infrastructure as the merchant/processor can spend to
defend from attacks. For another; the information needed to be kept
hidden from crooks (so they can't use it for fraudulent transactions)
is the same information that is needed in dozens of business processes
at millions of locations around the planet. We've claimed that even if
the planet is buried in miles of information hiding encryption, it
wouldn't be able to stop information leakage.

Most of these general security issues are unrelated to whether
mainframes or open systems are involved. Also, the cloud specific
security issues are unrelated to whether mainframes or open systems
would be involved.

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

The real estate bubble was about middle class capital loss and
great opportunity for affluent folks.

The student debt "pop" has more profound impact on future
generations and will last far longer than the current fiscal bump the
US is dealing with.

Without real education the earning power of future generations will
be lost making a very steep downward spiral that the US will take
several generations to recover if it is possible. The GOP have
consistently targeted education costs for spending cuts yet most
of the best GOP politicians are well educated.

The impact will be everywhere, loss of resources to create needed
infrastructure needed to support jobs. Loss of the organizational
and technical skills needed for innovation.

Recent from the democratic side in congress ... implies that efforts
stretched out for much longer that they actually seemed to. loc860-65:
At the December 2009 hearing, the three witnesses -- Breuer, Khuzami, and
Perkins -- said all the right things. Don't worry. We're on the case. These
are complex financial frauds committed by sophisticated actors. It takes
time and patience to develop these cases. We're reviewing the facts and
the evidence. We'll bring criminal or civil actions where the facts take
us. Stay tuned. At the time, we believed them. Unraveling sophisticated
financial fraud is an enormously complicated and resource-intensive
undertaking, because of the nature of both the conduct and the
perpetrators.

... snip ...

Note: Jan. 2009 I was asked to HTML'ize the Pecora hearings (30s
senate hearings into '29 crash, had been scanned at boston public
library fall of 2008) with lots of internal xrefs and lots of URLs
between what happened this time and what happened then (some
anticipation that new congress would have appitite to do something). I
worked on it for some time, but well before summer of 2009, I got a
call that it wouldn't be needed after all (references to enormous
piles of wallstreet money being spread around capital hill).

characterizes that it was actually over before it ever started, that the
economic A-team helped get the president elected but they were going to
choose the "swedish" solution (over the lingering "japan" solution) and
hold those responsible on wallstreet accountable. Instead the president
appoints the B-team, people that were involved in creating the economic
mess and not likely to hold anybody accountable.

The Price of Inequality: How Today's Divided Society Endangers Our
Future (Joseph E. Stiglitz) pg35/loc1169-73:
In business school we teach students how to recognize, and create,
barriers to competition -- including barriers to entry -- that help
ensure that profits won't be eroded. Indeed, as we shall shortly see,
some of the most important innovations in business in the last three
decades have centered not on making the economy more efficient but on
how better to ensure monopoly power or how better to circumvent
government regulations intended to align social returns and private
rewards.

... snip ...

Freefall: America, Free Markets, and the Sinking of the World Economy
(Joseph E. Stiglitz) pg271/loc5101-4
Standard economic theory (the neoclassical model discussed earlier in
this chapter) has had little to say about innovation, even though most
of the increases in U.S. standards of living in the past hundred years
have come from technical progress.56 As I noted earlier, just as
"information" was outside the old models, so too was innovation

... snip ...

...

another "The Payoff: Why Wall Street Always Wins", (referencing top
business schools) loc555-56:
Everyone wanted to be a banker or a management consultant; the dream
employers were Goldman Sachs, Salomon Brothers, and McKinsey. The
consensus among students was that only losers took jobs at companies
that actually made things, like IBM or Proctor & Gamble.

Boyd is credited with battle plan for desert storm ... but the final
action was terminated ... leaving it to be done again a decade later.
past posts and other refs to Boyd
http://www.garlic.com/~lynn/subboyd.html

How Bush's grandfather helped Hitler's rise to power; Rumours of a link
between the US first family and the Nazi war machine have circulated for
decades. Now the Guardian can reveal how repercussions of events that
culminated in action under the Trading with the Enemy Act are still
being felt by today's president
http://www.guardian.co.uk/world/2004/sep/25/usa.secondworldwar

snippet from 1154th engineering combat group status report from National
Archives (my wife's father commanded 1154th, frequently out in front
making repairs so armor and infrantry can move up):

On 28 Apr we were put in D/S of the 13th Armd and 80th Inf Divs and G/S
Corps Opns. The night of the 28-29 April we cross the DANUBE River and
the next day we set-up our OP in SCHLOSS PUCHHOF (vic PUCHOFF); an
extensive structure remarkable for the depth of its carpets, the height
of its rooms, the profusion of its game, the superiority of its plumbing
and the fact that it had been owned by the original financial backer of
the NAZIS, Fritz Thyssen. Herr Thyssen was not at home.

Forward from the DANUBE the enemy had been very active, and an intact
bridge was never seen except by air reconnaissance. Maintenance of roads
and bypasses went on and 29 April we began constructing 835' of M-2 Tdwy
Br, plus a plank road approach over the ISAR River at PLATTLING.
Construction was completed at 1900 on the 30th. For the month of April
we had suffered no casualties of any kind and Die Gotterdamerung was
falling, the last days of the once mighty WHERMACHT.

CALCULATORS

Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
Nonsense; the doubling of the rates was a "sunset" provision of the
law reducing rhem.

congress has hit on the idea that they get more money from sharply
partisian bills ... and ongoing money if instead of making them
permanent ... have them periodically expire and the process can be
repeated again and again. part of the motivation for references
to congress as Kabuki theaterhttps://en.wikipedia.org/wiki/Kabuki

and/or the most corrupt institution on earth.

CBO has during '0x decade that tax revenue was reduced by $6T and
spending increased by $6T (compared to baseline) for $12T budget gap
(compared to baseline that had all federal debt retired by 2010). much
of this occuring after congress let the fiscal responsibility act expire
in 2002 (required that spending had to be matched by tax revenue) ...
only $2T of the $6T spending increase (over baseline) last decade was
for the wars ... recent war reference:
http://www.garlic.com/~lynn/2012l.html#54 Singer Cartons of Punch Cards

the established tax shortfall and size of govenment increase (from last
decade) has on-going effects into this decade.

current partisian battle is over proposed *enormous* decreases in
Pentagon budget ... which only takes it back down to the 2006 spending
level. there was article that major military contractors are havesting
much more now from DOD than they were in 2006 ... but have fewer
employees than 2006 (the increase in revenue and having fewer employees
showing up in executive compensation). "threats" about proposed spending
reduction will result in loss of jobs ... fails to reference that there
has already been significant/greater loss of jobs as part of increasing
executive compensation (suggestion that returning to 2006 spending
levels should actually result in return to 2006 employment levels and
2006 executive compensation).

there has big thruput difference between i86 and risc ... risc having
out-or-order execution, branch prediction, speculative execution, etc
for a couple decades. last couple i86 chip generations have moved to
risc with hardware layer that translates i86 instructions to risc
micro-ops ... mitigating much of the thruput difference. Hyperthreading
(two simulated processors per core) is also used to further increase
instructions per second (by feeding execution units from two independent
instruction streams). Hyperthreading was worked on back in early 70s for
370/195 ... but never shipped to customers. The 370/195 was out-of-order
and pipelined but didn't have branch-prediction or speculative
instructions. Peak thruput was 10MIPS ... but most codes ran at 5MIPS
because of branch stalls. It was planned that two independent
instruction streams ... each running at 5MIPS effective thruput would
obtain aggregate of 10MIPS.

even z196 claims the introduction of out-of-order execution was big part
of thruput improvement from z10 to z196 ... with further out-of-order
enhancements coming with the newest generation. Announcements claim 50%
thruput increase for max EC12 over 80 processor z196 .. which would put
it about 75BIPS.

traditional 370 simulation has claimed 10:1 (with further improvements
in some of the commerical simuators with just-in-time "compilation"
... aka dynamic translation of repeatedly executive 370 snippets to
native for direct execution). e5-2600 is two socket (chip) with 8 cores
(processors) per chip for total of 16 processors benchmarked at
aggregate of 527BIPS ... which might yield as much as mainframe 53BIPS
(at 10:1) ... or approx. same as 80-processor z196. IBM has base price
for e5-2600 blade at $1815 ... compared to $28M for 80-processor z196.

Note analysis from couple days ago claims IBM sells $5.25M in mainframe
software, services and storage for every $1M in mainframe hardware. That
would imply customers spend closer to $175M for 80-processor z196 ($28M
+ $147M).

If the Amazon "supercomputer" at $4829/hr, 51,132 cores, $48M/annum were
running mainframe simulation (at 10:1) ... that would still be the
equivalent of 3,380 z196 80 processor machines or $625B (one-tenth of
the $6.25trillion from the previous post). The problem is would it
require the equivalent amount of IBM mainframe software (at the cost of
several hundred billion)?

Four socket e5-4600 blades are arriving ... which theoritically will be
1000BIPS machines ... but I haven't seen any published benchmarks yet
... four sockets (chips), 32 cores (processors), 64 hyperthreads ...
which theoritically could give mainframe 100BIPS per blade.

Way back when, when I was involved in doing ECPS (initially for 138/148)
... there was factor 10 times increase in thruput dropping segments of
vm370 kernel code into native "microcode". We were given that machines
had 6kbytes of space available for ECPS native microcode and were to
choose the 6kbytes of highest used vm370 kernel pathlengths. Old post
given the result of kernel pathlength timings ... ordered by percent of
total kernel time. 6kbyte cut-off accounted for 79.55% of vm370 kernel
execution time ... dropping it into m'code resulted in ten times speedup
(aka about 8% ... eliminating 72% of vm370 kernel time) ... aka low &
mid-range 370s use to all be 370 simulator with software runnong on some
native engine at approx. 10:1 overhead:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

at the time, mainframe DB2 complained that if I was allowed to
continue it would be a minimum of 5yrs ahead of them ... in
both scaleup and availability. misc. past posts mentioning
HA/CMP product
http://www.garlic.com/~lynn/subtopic.html#hacmp

also at the time, out doing marketing pitches, I coined the terms
disaster survivability and geographic survivability ... and was also
asked to write a section for the corporate continuous availability
strategy document ... but the section got pulled when both Rochester and
POK complained that they couldn't meet the requirements ... misc. past
posts mentioning continuous availabilityhttp://www.garlic.com/~lynn/submain.html#available

cfmpublic@NS.SYMPATICO.CA (Clark Morris) writes:
How much work can that z196 do compared with the 4829/hr Amazon cloud
you mentioned? Given the great disparity between costs per
instruction execution, on reading these posts it would seem that
getting to a secure, fault tolerant operating system on blade clusters
would be highly cost effective and that all new work should be moved
to that environment.

this is long-winded discussion in (linkedin) Greater IBM regarding
financial industry spending several billions on attempting to move
business critical applications off mainframes to "killer micros" in the
90s (contributed to lots of the press about mainframe death). The
efforts failed disastrously for some specific reasons. More than
a decade later ... when all of the reasons for the earlier failures
had been addressed ... there was still significant resistance and
risk adversion lingering because of the earlier failures.
http://www.garlic.com/~lynn/2012l.html#47 I.B.M. Mainframe Evolves to Serve the Digital World
also repeated in this ibm-main thread
http://www.garlic.com/~lynn/2012l.html#31 X86 server

for something totally different ... in the 70s, one of the online
virtual machine based commercial service bureaus (claims that these
virtual machine based services were the cloud of the 60s&70s and into
the 80s) ... developed a "capability-based" operating system for ibm
mainframe called gnosis. It was benchmarked doing ACP/TPF like
transaction at higher-throughput than ACP/TPF (on the same hardware)
... part of the explanation was the higher integrity, higher abstraction
... allowed things that couldn't be done with the low-level ACP/TPF
implementation. When M/D bought the business in the 80s, the
capability-based operating system was spun-off into its own company
(disclaimer: I was brought in to audit the implementation as part of the
spin-off).

current day ratio of memory access to processor cycle is similar to
60s ratio of disk access to processor cycle ... modern day cache
misses are comparable to 60s disk i/o latency (measured in terms of
processor cycles) ... giving rise to out-of-order execution, branch
prediction, speculative execution, hyperthreading ... as means of
providing overlapped execution during cache misses and memory access
delays ... techniques that risc have been working with for decades
... and introduction of out-of-order execution is credited with major
part of recent mainframe thruput increases.

Andrew Swallow <am.swallow@btinternet.com> writes:
The banker just persuaded the politicians that the companies were too
big to be allowed to fail, particularly in an election year. The rest
of us just got the bill. There was no reason why the resignation of
all the company directors could not form part of the conditions of the
loans.

"The Payoff" loc2694-98:
And Greenspan had admitted that Fed research "had been unable to find
economies of scale in banking beyond a modest-sized institution." A
decade ago, Greespan had continued, "I noted that 'megabanks being
formed by growth and consolidation are increasingly complex entities
that create the potential for unusually large systemic risks in the
national and international economy should they fail.' Regrettably, we
did little to address the problem."

... snip ...

Seems to be somewhat gratuitous, since Greespan was heavily involved
in deregulation ... including giving Weill an exemption for takeover
of Citi while Congress was being lobbied to repeal Glass-Steagall.

in the google+ discussion, somebody noted that the 5yr statute of
limitation has been allowed to expire for much of what went on.

I've mentioned before about over a decade ago reviewing industry
publication that gave average of top regional institutions compared to
the average of the national institutions for several thousand
measures. The data showed the regional institutions slightly more
profitable than national instituations.

Singer Cartons of Punch Cards

Dave Garland <dave.garland@wizinfo.com> writes:
The near-collapse of the Detroit/Flint auto industry was the
culmination of a 50-year process.

early 80s, there was article (washington post) calling for 100%
unearned profit tax on us auto industry. The scenario was that the
foreign auto import quotas was to reduce competition ... giving us auto
industry significantly increased profits to completely remake themselves
(into something more competitive). Instead they just pocketed the money
and continued the status quo and business as usual.

1990, the industry had C4 taskforce to look at remaking themselves,
plans were to heavily leverage technology and they invented
participation from technology vendors. during the meetings they could
clearly articulate the competitive issues, foreign competition and what
needed to be done. however it is evident that they still weren't able to
change the status quo.

as an aside ... many of the same names & entities that show up in
Prescott&Walker history and show up in the Smedly Butler references,
also show up playing major roles in the Pecora hearings (senate hearings
into '29 crash resulted in Glass-Steagall ... and some prosecutions).

I've mentioned several times that Jan2009, I was asked to HTML'ize the
Pecora hearings (had been scanned fall of 2008 at Boston public library)
with lots of internal cross-references as well as URLs between what
happened this time and what happened then (some anticipation that the
new congress had some appetite to do somehting). After working on it for
some time, I got a call that it wouldn't be needed after all (references
to enormous piles of wallstreet money being spread around capital hill).

Peter Flass <Peter_Flass@Yahoo.com> writes:
Probably the difference in the CEO's pay. The worst thing a
corporation can do is locate its headquarters in a large city. In a
smaller city a bank president, for example, would be the biggest fish
in a small pond. In a large city I think they compete with one another
in extravagant lifestyles. Of course with globalization they're now
probably competing with people in Berne of Shanghai.

I've periodically (*also*) commented in the past the only apparent
motivation for too-big-to-fail was executive pay proportional to
corporation size ... since the size seem to serve no other useful
purpose.

there have been various references that egos were major factor behind the
latest mess (not just the money).

AMEX had also been in bidding war with KKR (large private equity firm)
for the reverse-IPO of RJR and KKR wins. KKR then runs into problem with
RJR and hires Gerstner away from AMEX to turn-around RJR. IBM board
then hires Gerstner to resurrect IBM ... afterwards he goes on to be
head up Carlyle (another large private equity firm).

Along the way, AMEX in '92 does ipo/spin-off of major dataprocessing
unit as First Data (largest IPO up until that time). More recently KKR
does reverse-IPO of First Data (taking it private again, disclaimer I do
a stint as chief scientist at first data). recent references to first
data

And Greenspan had admitted that Fed research "had been unable to find
economies of scale in banking beyond a modest-sized institution." A
decade ago, Greespan had continued, "I noted that 'megabanks being
formed by growth and consolidation are increasingly complex entities
that create the potential for unusually large systemic risks in the
national and international economy should they fail.' Regrettably, we
did little to address the problem."

from above:
Since the crisis hit, the Federal Reserve has attempted to juice the
economy through a program that's called Quantitative Easing, which is
buying long-dated government bonds and mortgage backed securities It's
the same scheme that the Bank of Japan has tried in its long battle
against saggy growth and deflation.

mentions that economic A-team helped get the president elected but they
were going to choose the "swedish" solution (over the lingering "japan"
solution) and hold those responsible on wallstreet accountable. Instead
the president appoints the B-team, people that were involved in creating
the economic mess and not likely to hold anybody accountable.

also from "Forget Bernanke" article
Specifically he cited the "portfolio balance channel", which means that
QE would work by reducing the supply of super-safe Treasuries and
Mortgage Backed Securities, and instead push investors into other areas
(like corporate bonds), thus depressing yields and borrowing costs in
the private sector. Think of it this way: During the crisis, everyone
sought refuge in the safety of Treasuries. Bernanke was now seeking to
deprive them of this safety valve, and force their cash into areas where
it might do some good in the economy.

... snip ...

In FED documents (that were released under FOIA after year of
litigation) ... FED provides upwards of $30T in loans to too-big-to-fail
... in theory for them to use the money to loan to mainstreet. Instead
the institutions use it to buy treasuries making huge profit off the
spread between nearly zero percent loans from FED and what treasuries
were paying (large amounts then used to pay bonuses for their
executives). Bernanke then is asked about it and says he has no way of
forcing the too-big-to-fail to use FED money for loans to mainstreet.

Documents also have FED buying huge amounts of toxic CDOs from
too-big-to-fail for 98cents on the dollar (presumably the "super-safe"
in the article *only* applies to Treasuries and is not met to infer
anything about Mortgage Backed Securities).

$700B in TARP was originally appropriated to buy toxic assets being held
off-balance. However, just the four largest too-big-to-fail were
carrying $5.2T in triple-A rated toxic CDOs off-balance at the end of
2008.
Bank's Hidden Junk Menaces $1 Trillion Purge
http://www.bloomberg.com/apps/news?pid=newsarchive&sid=akv_p6LBNIdw&refer=home

earlier in the fall of 2008, several tens of billions of the triple-A
rated toxic CDOs had gone for 22cents on the dollar ... with only $700B
appropriated ... there was no way that it could address a problem of
that magnitude. Obviously buying off-balance toxic CDOs at 98cents on
the dollar was another gratuitous gift for the too-big-to-fail (if the
too-big-to-fail had been forced to big the triple-A rated toxic
CDOs back on to the balance sheet, they would have been declared
insolvent and forced to be liquidated)

in total there was an estimated $27T in triple-A rated toxic CDOs
done during the bubble
http://www.bloomberg.com/apps/news?pid=newsarchive&refer=home&sid=a0jln3.CSS6

Anne & Lynn Wheeler <lynn@garlic.com> writes:
In FED documents (that were released under FOIA after year of
litigation) ... FED provides upwards of $30T in loans to too-big-to-fail
... in theory for them to use the money to loan to mainstreet. Instead
the institutions use it to buy treasuries making huge profit off the
spread between nearly zero percent loans from FED and what treasuries
were paying (large amounts then used to pay bonuses for their
executives). Bernanke then is asked about it and says he has no way of
forcing the too-big-to-fail to use FED money for loans to mainstreet.

Barofsky is brought in as inspector general for TARP program ... which
had been appropriated initial $350B with another $350B available for
purchase of toxic assets from the too-big-to-fail. Apparently treasury
(under Paulson) from possibly the beginning, hadn't intended to
buy/purchase toxic assets. "Bailout" has Paulson telling congress that
he was making loans to TBTF instead so that they could turn around and
lend to mainstreet. Much of this had already happened by the time
Barofsky came on board and those loans had no strings attached
.. Barofsky uses congressional leverage for subsequent loans to at least
require the borrowers to report what they were using it for (apparently
none for lending to main street).

Supposedly treasury had also told congress (besides the TBTF would use
the money to make loans to mainstreet), that the loans would only be to
solvent TBTF that weren't on the verge of failure (but other reports was
that they knew that the TBTF getting the loans would have failed w/o
them, aka ... and that they weren't going to be using the money to make
loans to mainstreet) ... several iterations of believing TBTF would make
loans to mainstreet.

and ... Bailout, pg85/loc1743-47:
The mortgage-backed securities were a huge boon for the banks. At every
stage of their creation and sale, the Wall Street institutions offering
them raked in large fees, and every firm that participated in the
transactions (from loan origination through the final sale of the bonds)
enjoyed huge profits. With high credit ratings in hand, the AAA subprime
bonds became wildly attractive to investors and other financial
institutions because they paid a higher interest rate than other
AAA-rated bonds, such as those issued by the U.S. government, and
because regulators began giving such highly rated bonds favorable
treatment.

... snip ... Bailout, pg85/loc1756-59:
For their part, the banks buying the mortgages weren't terribly
concerned about the obvious problems with the mortgages being thrown
into those pools. The profits from the securitization mill were too
high, and the losses would not be borne by them but by the investors
buying the bonds. Later investigations would demonstrate that several of
the largest banks had been on full notice that the mortgages they were
packaging were littered with fraud but continued to sell and package
them.

... snip ...

The individual compensation was so huge that it easily offset any
concerns that there might have been about the consequences to their
institution, the economy, and/or the country.

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

jmfbahciv <See.above@aol.com> writes:
The muni market has dried up. One of those economic boosting deals
gave the option of government entities to issue a 5% bond but pay <3%
(according to my broker and I still don't understand this one).
The bond interest paid out is taxable so I'm assuming the 2%
difference is getting covered by the Fed? Whatever is being done,
it sounds squirrely and you can't find a muni bond for income.

as it dawned on investers that it was possible to buy triple-A ratings
from the rating agencies ... they started to worry whether any of the
rating agencies' ratings could be trusted ... and the muni-market
completely froze. Buffett then stepped in with muni insurance to
unfreeze the muni-market.

the muni-market has longer term structural problems ... 1) there has
been some number of legal actions against wallstreet about outright
fraud in bond offerings 2) some number of municipalities have become
collaterial damage in the economic mess. During the height of the
boom, there was big overbuilding in the real estate market, many
municipalities had to build-out their infrastructures for the new
developments ... issuing bonds to cover the cost ... assuming the debt
service would be covered by taxes from all the new houses. When the
crash happened ... lots of municipalities weren't getting the tax
revenue to cover debt service fro the new bonds, 3) general collatoral
damage with crash of the housing market there has been corresponding
crash in the real-estate taxes that fund the municipalities (and used
to service bond debt).

the part of both treasury and fed giving TBTF nearly free money because
the TBTF would (of course) turn around and lend to mainstreet ... seems
to have been total farce (just facade told to congress and the public
... pure Kabuki theater ... since TBTF were given several different
opportunities and didn't do it).

"Bailout" has Barofsky dumb-founded that treasury was giving all the
TARP money to TBTF in the closing days of 2008 ... and that no strings
were actually attached to the funds ... just claims that they expected
that TBTF would feel compelled to use the TARP-funds to lend to
mainstreet .... and seemed to be totally surprised when they
didn't. these are a bunch of former Goldman-Sachs wiz-kids (joke during
the last decade that US Treasury was Goldman-Sachs branch offine in
washington dc). The story-line was then repeated with the enormous funds
from FED for TBTF (and still no lending to mainstreet).

You have some of the top wallstreet financial wizards (at treasury
having run one of the most "successful" TBTF) effectively claiming they
have no idea how TBTF operates (not able to predict what TBTF will do
when given enormous piles of money with no strings attached).

The current line is to periodic have FED buy up much of US Treasuries
... so investors are forced out of the US Treasury market and hopefully
actually invest in mainstreet.

PaulGBoulder@AIM.COM (Paul Gilmartin) writes:
And here, I find myself in rare agreement with John G.'s view
(if I understand correctly). A char[] containing no \0 is a perfectly
valid array of char. It is not a string, by C's convention, and there
is no requirement that a char[] represent a string.

the mainframe TCP/IP stack from the 80s was done in vs/pascal and had
none of the C-language buffer length related problems. The
implementation had a few other performance issues ... getting
44kbytes/sec thruput using nearly whole 3090 processor. I did the
changes for RFC1044 support and in some performance tests at cray
research got channel media thruput between 4341 and cray using only
modest amount of 4341 processor
http://www.garlic.com/~lynn/subnetwork.html#1044

also, air force performance evaluation of Multics (implemented in PLI)
noted that it had no buffer length related problems. Old post about
IBM Research update of the Air Force Multics study
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation

This is post about analysis I did of the Mitre CVE exploit database
... looking for ways to improve my merged security taxonomy & glossary
(and how you do you structure thinking about security)
http://www.garlic.com/~lynn/2004e.html#43 security taxonomy and CVE

I suggested to mitre that they start requiring reports to have a
little more structured information since they were quite free-form at
the time. Their response was that they were lucky to get reports in
any form at all ... adding structure form requirements afraid some
people would just not do the report (although they have since started
advising about more structure in the reports). Later , NIST came out
with analysis that exploits were approx. nearly 1/3rd buffer related,
1/3rd automated script execution, and 1/3rd social engineering (with
various other misc.).

a couple weeks later cluster scaleup is transferred and we are told we
couldn't work on anything with more than four processors
... motivating us to leave. A couple of the other people mentioned in
the meeting, later leave and show up at small client/server startup
responsible for something called "commerce server". We get brought in
as consultants because they want to do payment transactions on the
server, the startup had also invented this technology called "SLL"
they want to use, the result is now frequently called "electronic
commerce".

Part of the deployment for "electronic commerce" was developing
something called a "payment gateway" ... sits on the internet and
handles transactions between webservers and the payment networks (we
periodically refer to it as the original SOA). misc. past posts
mentioning payment gateway
http://www.garlic.com/~lynn/subnetwork.html#gateway

Part of protection for the payment gateways there are multiple layers
of firewalls and other kinds of filters. A common internet attack is
long strings ... attempting to leverage buffer-overflow
vulnerabilities found in about anything implemented in C-language
... so part of the intermediate security layers are checks for
excessive long strings.

We also have to do audits/reviews of SSL, digital certificates,
certificate issuing authorities, etc ... and come up with some
requirements about how things are deployed. Almost immediately the
requirements are violated and we start referring to it as "comfort
security" (aka security that provides feeling of comfort to all the
users). misc. past posts mentioning SSL, certs, CAs, etc
http://www.garlic.com/~lynn/subpubkey.html#sslcert

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

Bailout pg157/loc3106-9
HAMP was not separate from the bank bailouts; it was an essential part
of them. From that perspective, it didn't matter if the modifications
failed after a year or so of trial payments or if struggling borrowers
placed into doomed trial modifications ended up far worse off, as long
as the banks were able to stretch out their pain until their profits
returned.

pg163/loc3206-8
In the short executive summary that Issa cited in his release we
didn't give the details about what the $23.7 trillion figure really
represented, instead stating that "the total potential Federal
Government support could reach up to $23.7 trillion"

... snip ...

i.e. none of the programs from the government were for the public,
they were all for the banksters ... everything else was pure
fabrication.

"Confidence Men" and "Bailout" pretty much have everything a bankster
give-away from the beginning. The congressional staffers "How
Republicans Went Crazy" and "The Payoff" describe efforts that appear
to try and help the public, just were never successful.

from above:
The mortgage settlement by State attorneys general marks a new low for
America. A massive criminal conspiracy -- the Mortgage Electronic
Registration Systems (MERs, see Wikipedia), plus large-scale perjury
("robo-signing" foreclosure papers) and fraud before our courts. All
settled with a slap on the wrist to the banks. It teaches large
corporations thay they lie beyond the law, a large step beyond the
traditional lax enforcement of laws against big businesses.

originally posted after attending navy history conference last year
... the theme was on 100th anniv. of navy aviation ... but there was
lots of discussion about UAVs including asking the academy students
how many were planning on being naval aviators.

The bigger the bureaucracy, the more there are those with vested
interests in the status quo, and the more resistance to change. One
agent of change is major failure .... saw that with IBM ... and board
bringing in Gerstner to resurrect the company.

from above:
Anyway, with a double-stuffed machine, you can in theory get 512 cores
into a single system image, but it is not clear if AIX and Linux will be
able to see more than 1,024 threads as they currently do; the IBM i
operating system tops out at 128 threads in a single image at this
point, with a special patch to boost it to 256 threads, and is woefully
overdue for the same loving that AIX and Linux have gotten since 2010 to
at least see 1,024 threads.

... snip ...

i.e. with four hyperthreads per core and 512 cores in a single
multiprocessor would yield 2048 hyperthreads (aka the appearance of 2048
processors)

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

in lots of discussions about C language string&buffer conventions
being one the primary sources of programming errors ... there were
analogous with careful drivers never having accidents and therefor
there are no need for bumpers, safety glass, crash zones, seatbelts,
padded dashboards, airbags, etc.

the more straight-forward analysis is that buffer length management is
left to the programmer ... always having to manually manage whether
the implicit length (of null terminated string) fits within target
storage area. I've compared it to assembler language programming where
a major manual effort on the programmer was managing register contents
... and mis-managed register contents has been major assembler
programming error ... especially in complex programs with large number
of code paths ... and at any particular point in execution ... did all
possible execution paths correctly initialize registers.

It turns out that one of the benefits attributed for moving to
C-programming ... is it allows system level programming while
alleviating manual effort of the programmer managing the register
contents. However, it has trade-off the elimination of the manual
register content management effort with the buffer length manual
management effort.

Long ago and far away (in the very earliest days of rexx before
released to customers)... I wanted to demonstrate the power of REXX
... and selected IPCS ... which was a large, assembler implemented
application. Objective was to completely re-implemented IPCS in REXX
... working half-time over 3month period ... with the new
implementation having ten times the function and with ten times the
performance (some coding slight of hand to make an application in REXX
run ten times faster than corresponding application in assembler). I
finished early ... so I started doing analysis of kinds of failures
and their failure signatures ... developing an augmented library of
IPCS procedures that could be automated to look for the various kinds
of failure scenarios. Misc. past posts mentioning DUMPRX
http://www.garlic.com/~lynn/submain.html#dumprx

I had assumed that it would be released to customers as IPCS
replacement ... which never happened for whatever reason ... although
it eventually came to be used by all internal datacenters and nearly
all customer support PSRs. I eventually managed to get approval for
making presentation at user group meetings about how it was
implemented ... and within a couple of months, similar implementations
started to appear from other vendors.

Two of the most common (failure modes) were 1) anomolous code path
failure to establish register contents (required at later point) and
2) dangling buffer pointers (aka asynchronous operation using pointer
to storage area that was no longer active ... the particular storage
area no longer active and/or re-allocated for some other purpose).

Most higher-level languages eliminate manual programmer effort in
managing register contents. One of the characteristics claimed for
languages like Java & LISP is having eliminated programmer manual
managed storage ... not only doesn't have C-language buffer length like
problems ... but also has eliminated dangling pointer problems.

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

tony@HARMINC.NET (Tony Harminc) writes:
There *was* a single-chip 370 produced by someone in the late 70s - a
"168i". I think it was a university or research institute, but not
IBM. I'm not finding anything on Google with a casual search, but
things like this are easily overwhelmed.

SLAC did 168E ... basically could run problem state fortran at 168
speed ... for data collection/reduction along the accelerator line
... long ways from single chip.

168 had been four circuits per chip, 3033 initially was 168 logic
initially layed out on something like 40circuits per chip ... but just
using 4 circuits in each chip ... getting 20% chip improvement. during
development there was some rework of part of the 168 logic to make
better use of higher chip density ... get 3033 up to 50% faster than
168.
http://www.jfsowa.com/computer/memo125.htm

i've frequently claimed that John Cocke's 801/risc was reaction to
horrible complexity of (failed) FS effort ... initially simplified (aka
reduced instruction set) for single chip implementation ... and then
later simplified instructions that were all single machine cycle. misc.
past posts mentioning future system
http://www.garlic.com/~lynn/submain.html#futuresys

360s, 370s, etc ... have been microcode implemented on variety of other
kinds of engines. circa 1980 there was an effort to replace the wide
variety of internet microprocessors used for controllers, low&mid range
370s, the planned as/400 replacement for s/38, etc ... all with 801/risc
Iliad chips. For various reasons the efforts floundered and they went
back to doing custom processor implementations.

It took another couple decades ... but lots of stuff is now risc in one
way or another (as previously mentioned the past couple generations of
i86 are risc processors with hardware layer translating i86 to risc
micro-ops).

I had also been working with NSF on what was to become NSFNET backbone
(i.e. tcp/ip is the technology basis for the modern internet, NSFNET
backbone was the operational basis for the modern internet, and CIX was
business basis for the modern internet). Above refs. that I had to find
standin for me doing presentation to head of NSF ... because of rack
cluster effort meeting. misc. past posts mentioning NSFNET
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

Lots of low & mid-range clone 370 vendors were starting to spring up all
over the place. Somebody in Siemens Germany had somehow acquired a
proprietary ROMAN document ... and was trying to get it returned to IBM
with all fingerprints removed. He sent it to somebody at Amdahl in
silicon valley ... who arranged to hand it over to me.

Note that both DEC and Apollo (along with hp) are heavily into
distributed environment, heterogeneous network/system/enterprise
management, and networks. Note that heterogenous means more than OSI,
TCP/IP, UNIX, etc ... it means interoperability between all of them
along with DECNET, VMS, XNS, etc.

Apollo's FDDI group is heavily involved in XTP and the former manager
of the Apollo FDDI group (they've been active for some time and
spending lot of time optimizing performance of high thruput adapters)
left Apollo and formed synernetics (he was involved with XTP at Apollo
and synernetics is a XTP/TAB member). They are working on initial cut
of FDDI station management (SMT ... and have been out talking to a
number of groups, including IBM ... I also believe he has even had
contacts with <aaaaaa>).

Distributed 370s have a hard time keeping up. Way back in history
(someplace), I spent a lot of time up at SLAC (there is tight coupling
between SLAC and CERN). At that time SLAC was doing the 168E, a
bit-slice processor that would run standard 370 Fortran programs. They
technology has been improved and now CERN & SLAC are calling it a
3081E (i.e. the processing power of 3081). The design was to have one
of these processors at each of the (large number of) data collection
points.

Something that will be competing with this will be the 370 simulator
that <xxxxxx> has done for the SUN4. He currently has VM/370
running at about 168 thruput on the old SUN4 (big register memory are
super for large integrated applications but state switch overhead can
be heavy/horrible ... something that we are currently grappling with
... some possibilities exist for pipelining/overlapping state switch
like <yyyyyy> is doing with Vector Buffer architecture). I've
known <xxxxxx> for a long time and he is experienced at what he
does (he was lead development programming at Amdahl, then chief
architect at 2pi, did DOS port for Olivetti, did 370 software
ports/stuff for Nixdorf and most recently was contract to Boca West
doing the OSI implementation for CPD). 168 thruput means he is
effectively getting about 4:1 ratio of Sparc instructions to 370
instructions (implying that he could get 12.5 370 mips on the recently
announced 50mip Sparc chip).

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
OK, I was stretching it a little. Some versions of S/360 were designed
to test out different ideas. The 360/85 was the first with cache.
IBM did much study on locality before doing it, but it still had
to be actually built. (And them ended up almost as fast as
the 360/91 for many programs.)

The 360/67 was the S/360 try at virtual storage, as I understand
it more for timesharing than for larger addressing space for
batch jobs. (Stanford ran ORVYL on their 360/67 using it.)

I agree it wasn't planned in advance as a test for S/370 paging,
and in fact there were some changes in the paging hardware between
the 67 and S/370. Even so, it did allow people (and IBM) to get
to understand paging enough to add it to S/370.

Yes, the 155 and 165 didn't originally come with virtual addressing,
and I don't remember by now exactly when they planned it as an
add-on (and expensive) option.

370 batch larger address space ... was SVS (&VS1,DOS/VS) ... basically
single virtual address space ... basically MVT laid out in single
16mbyte virtual address space (something analogous to what some
univ. had done running MVT in 16mbyte virtual machine ... with some
handshaking between VM and MVT). There was a little bit of hack on the
side of MVT to setup the virtual tables and handle page fault. The major
code hit was to i/o supervisor (aka EXCP processing).

MVT (os/360) convention were library code running as part of application
built I/O channel programs. Pointer to the (user address space) channel
programs were passed to the kernel/supervisor with an EXCP supervisor
calle. Hardware executed the I/O channel programs with real addresses.
In the move to SVS ... all the passed channel programs were built by the
application using virtual addresses. Before the channel programs could
be turned over to the hardware ... EXCP processing now had to convert
all the virtual address to real addresses. The routine that performed
this in CP67 (for virtual machine simulation) was CCWTRANS. Ludlow did
early build of SVS running on 360/67 by hacking copy of cp67 ccwtrans
into the MVT EXCP code. past post discussiong Ludlow doing the CP67
CCWTRANS hack for MVT and also discussing justifying virtual memory for
all 370s:
http://www.garlic.com/~lynn/2011d.html#73 Multiple Virtual Memory

above references study that showed standard MVT application programs
tended to only use 1/4th the memory in a partition ... resulting in
"ability to run 16 initiators simulaneously on a 1 megabyte system".
The issue was systems tended to be extremely I/O throughput limited
... processor idle while applications waited for I/O operations. To
improve processor utilization (and usefulness) required being able to
run multiple things simultaneously (having work waiting when something
stalled waiting for i/o operations). As mentioned in the above, the cp67
experience had no input in the decision ... and tss/360 (the other
system for 360/67) had little input ... it was more of a theoritical
calculation.

The tss/360 experience was more directly involved in the
single-leve-store memory mapped design for the (failed) future system
effort (that was going to completely 360/370 with something radically
different). misc. past posts mentioning (failed) FS
http://www.garlic.com/~lynn/submain.html#futuresys

The 370 architecture book (called "red book" for its distribution in red
3-ring binder) specified the full 370 virtual memory architecture. The
retrofit of adding virtual memory to 370/165 was major effort and the
schedule was slipping. In order to make up time, there was decision to
drop various pieces that 165 was having trouble with. That resulted in
the other models going back on removing the dropped features ... as
well as rewriting software that had already been developed using the
dropped features ... including a major hit to vm370/cms.

As an aside, the "red book" was one of the early mainstream corporate
documents moved to cp67/cms "script" (been ported from CTSS runoff)
document formating. There were conditional variables and script command
line option would select whether the principles of operation subset
would be formated or the full "red book" would be formated. The "red
book" contained unannounced hardware features, unannounced instructions,
lots of engineering, implementation, and trade-off notes for various
features (each instruction tended to have a lot of notes about why it
was justified and engineering considerations on diferent models, etc).

basically a couple M68k executing subset of vm370 ... code-named
washington. it didn't support i/o ... so vm370 was modified to
communicate with a monitor running under dos on the 8088 for all i/o
functions. it provided approx. 100kip 370 with 384kbytes of memory
... little bit faster than 370/115. however, since all disk i/o (paging,
cms file, etc) was being done on 100ms (per block) dos hard disk. By
that time, vm370 and cms had gotten quite a bit bloated ... much larger
than cp67/cms that would run on 256kbyte 360/67. Also any kind of disk
i/o (paging, file activity) could become extremely painful ... compared
to what one was use to with real mainframe disks.

I got con'ed into doing some work on it ... first thing simple paging
tests showed almost any cms application would page thrash in the
pageable pages available left over after vm370 kernel fixed storage size
(from 384kbytes) ... exhaserbated by the paging on dos xt disk. I got
blamed for several month schedule ship in the product while they
upgraded the memory from 384kbytes to 512kbytes ... to cut down on
severe paging problems. However, cms applications that tended to be much
more file intensive than (and fared poorly in comparison with)
equivalent applications developed for the DOS/XT resource limited
environment.

I had tried to start a project to implement a super lean and fast vm370
replacement kernel in pascal. As a demo I had re-implemented the vm370
kernel spooling function in pascal running in virtual address space. My
objective was to enormously increase the throughput and performance
compared to the kernel assembler implemented equivalent.

I had another agenda ... I was also doing high-speed data transport
project ... and for vm370 vnet ... which was dependent on vm370 spool
... I needed multi-megabyte sustained thruput to drive the links I had.
misc. past posts mentioning hsdt
http://www.garlic.com/~lynn/subnetwork.html#hsdt

I indirectly referenced it in previous post regarding work with NSF on
what was to become NSFNET backbone ... also original mainframe tcp/ip
product was done for vm370 in pascal ... and I did the rfc1044
enhancements that got sustained channel thruput (between 4341 and cray
machine using only modest amount of 4341 processor, about 500 times
improvement in bytes moved per instruction executed). misc. past posts
mentioning NSFNET backbone
http://www.garlic.com/~lynn/subnetwork.html#nsfnet

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

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
But a large address space doesn't help much if you don't have
backing store for it. For the 360/67 that would have been 2314s
at about 29MB or maybe 2301 drums.

The 2305, popular paging device for S/370, has a S/360 series 23xx
number. Maybe they could also attach to the 360/67.

there are also some real throughput gatchas about doing memory-mapped
filesystem ... which contributed to tss/360 throughput issues. As
undergraduate I did simulated user synthetic benchmarks (fortran
compile, bind/link, execute) for cp67/cms on 768kbyte 360/67 for 30
users. The IBM/SE was doing a lot of work with tss/360 and did
equivalent script. The tss/360 benchmark for 4 users had much worse
response, throughput, etc ... than the equivalent script on cp67/cms
with 30 users.

The failed Future System effort was adapting pretty much the same
tss/360 single-level-store model and would have suffered similar extreme
performance issues (but it had much more severe problems that it never
even got that far). I was at the science center and figured I could do
paged-mapped filesystem for CP67/CMS that avoided many of the pitfalls
in the tss/360 implementation ... and contributed to my periodically
ridiculing FS activities (and thinking what I already had running was
significantly better than anything they planned). misc. past posts
mentioning memory mapped operation:
http://www.garlic.com/~lynn/submain.html#mmap

much of move to 31-bit in XA was primarily an MVS problem ... unrelated
to memory-mapping files. In initial move from MVT to SVS everything was
in single virtual address space ... and os/360 over the years had
extensively made use of pointer passing API paradigm. In the move from
SVS to MVS ... each application got its own 16mbyte virtual address
sapce ... but because of the pointer-passing API ... an 8mbyte image of
the MVS kernel was included in every application virtual address space.

MVT&SVS had some number of "subsystems" (system function) that sat
outside the kernel. In the move to MVS, these subsystems were given
their own virtual address space. The problem was subsystems no longer
had addressing to the pointer-passed parameters in the application
address space. To address this the "COMMON SEGMENT" was created ... a
part of every virtual address space ... for which dedicated storage
could be obtain for passing parameters & data back&forth between
applications and subsystems. This area started rapidly growing for large
installations ... basically having to be proportional to combination of
number of subsystems and number of concurrent applications. By the late
70s, many large installations had 4-5mbyte CSA (common segment renamed
common system area) and were threatening to increase to 5-6mbytes ...
i.e. large installations were under threat of the CSA increasing to
8mbytes ... so that the kernel was 8mbyte of every 16mbyte virtual
address space and CSA was the other 8mbyte ... and there was nothing
left to run applications.

There was internal MVS fanatic installation at the chip plant in
Burlington that was being threatened with having to move to VM370. They
had a large fortran chip design application that ran on a carefuly
constructed MVS systems that had a one mbyte CSA ... just barefly
fitting in the remaining 7mbytes. They were constantly have to do
significantly design and programming just to maintain fitting in
7mbytes. They were offerred vm370/cms that allowed nearly the whole
16mbytes ... beside thruput being slightly better ... even for
computation intensive fortran application.

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
Did the decision to do VS for S/370 come from the ability to do
large address space batch processing? That is what it looks like.
But also it made timesharing much easier.

XT/370 and AT/370 used a 68000 with custom microcode and a second
68000 with standard microcode. The software for it was VM/PC.
Note that the later P/370 and R/370 cards implemented the full
architecture and ran stock operating systems.

between xt/at/370 and p370/p390 was a74 (7437) done in POK by the same
group that had done the 3277GA (i.e. large tektronics graphics tube that
plugged into side of 3277 terminal) ... "a74" was their POK dept.

the 4300s saw huge uptake with large corporate orders (hundreds at a
time) ... being placed out in departmental areas ... sort of the leading
edge of the distributed computing tsunami. MVS lost out on this for a
long list of reasons ... including requiring significant support staff
for each MVS system. The other part was very low environmental footprint
... which included FBA disks. MVS only supported CKD (and still doesn't
even after it has been decades since they stopped making real CKD disks)
... and the only (new) CKD was 3380 ... which had a high environmental
footprint. The only mid-range disk was 3370 ... which was FBA only.

Since the 3033, MVS also had a set of pecular microcode enhancements
(even before xa) which weren't available on 4300s. A large corporate
customer did come in and say he would order 800 4341s if it ran MVS. As
a result, some really ugly, gorping MVS specific microcode had to be
retrofitted to 4341 ... and there was 3375 disk ... which was CKD
simulation on 3370 FBA (it didn't address the enormous support staffing
required to support MVS).

The followon to 4331/4341 were the 4361/4381 ... but as I've mentioned
they never saw the huge explosive growth of the 4331/4341 ... the
distributed computing market was starting its move workstations and
large PCs.

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

sipples@SG.IBM.COM (Timothy Sipples1) writes:
Keep in mind that for 1975 this was absolutely amazing technology, but
amazing technology required some expense. Being early is pricey. If the
5100 debuted in, say, 1977 or 1978, it would have still been well timed but
could have dramatically reduced the chip and board count. I also think the
small built-in monitor could have been sacrified (at least as an option) in
favor of a display port of some kind -- ideally RF for TV hookup. And IBM
might have gone with a diskette drive for storage -- the 5100 was too early
for the 5.25 inch drive, which debuted in 1976. Finally, if IBM had
provided a little more guidance on the 370 subset instruction set they
implemented, software developers could have taken over from there.

So I think the 5100 could have been a nice 5110 by tweaking the recipe a
bit. But history didn't happen that way.

from above:
The 5100 was based on IBM's innovative concept that, using an emulator
written in microcode, a small and relatively cheap computer could run
programs already written for much larger, and much more expensive,
existing computers, without the time and expense of writing and
debugging new programs.

Two such programs were included: a slightly modified version of APL.SV,
IBM's APL interpreter for its System/370 mainframes, and the BASIC
interpreter used on IBM's System/3 minicomputer. Consequently, the
5100's microcode was written to emulate most of the functionality of
both a System/370 and a System/3.

IBM later used the same approach for its 1983 introduction of the XT/370
model of the IBM PC, which was a standard IBM PC XT with the addition of
a System/370 emulator card.

... snip ...

part of the issue was apl code was fairly dense ... and apl\360
workspaces were typically 16kbytes (some systems offerred 32kbytes).

cambridge science center had taken apl\360 ... stripped out all the
multitasking and swapping stuff and got it to run under cms workspace
as large as virtual memory ... for cp67 cms\apl. some amount of work
had to be done on how apl\360 storage since it tended to use all
available workspace ... which resulted in page thrashing in virtual
memory environment. there was also an cms\apl API to access system
services (including file i/o). The combination of large workspace and
file i/o allowed doing a lot of real-world applications (that couldn't
be done with apl\360). The business planners in Armonk loaded the
holiest of holy data (detailed customer profiles) on the cambridge
system for business modeling in cms\apl. This also created something
of security issue since cambridge also allowed non-employee access
from various institutions in the cambridge area (students, staff,
faculty).

palo alto science center then did the enhancements to make vm370
apl\cms ... they also did the 370/145 apl microcode assist and the
5100.

the person that did 370/145 apl microcode assist was also instrumental
in many of the fortan hx performance enhancmenets.

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

R.Skorupka@BREMULTIBANK.COM.PL (R.S.) writes:
WRONG!
I meant it's hard to justfiy the choice: to buy IFL (plus rest of
mainframe) or x64 servers. I meant Linux on IFL is *much* more
expensive than on x64 servers. Things like power, cooling, floor
space, staffing won't change it, but the software licenses could do
it.
BTW: I did not mention RAS, but not everyone will pay for good
RollRoyce, some of us choose Toyota.

z196 with 80 processors is rated at 50BIPS (besides increase from 64
to 80 processors over z10 at 30BIPS ... was the introduction of
out-of-order execution ... something that had been used in risc for
decades ... and the more recent I86 ... especially after they moved to
risc cores with hardware layer that translated i86 to risc micro-ops
for execution).

At $28M ... z196 at 50BIPS is 625MIPS/processor, $560,000/BIPS and
$350,000/processor. z196 80 processor is also 31.7kW ... or
634watts/BIPS. So far ec12 is 101 processors and 1.5times processing
of z196 (say 75BIPS) with 26% increase in number of processors. ec12
processors are running 6percent faster than z196 processors ... so
much of the rest of the performance improvement may be the statements
about improvements to out-of-order execution ... guestimate 75BIPS/101
... aka 743MIPS/processor (compared to 625MIPS/processor for z196)

Analysis from last week is that IBM earns roughly $5.25M in mainframe
services, software, and storage for every million in in mainframe
processor ... so a $28M z196 would represent total of $175M.

IBM has base list price of $1815 for e5-2600 blade. High-end e5-2600
is benchmarked at 527BIPS for two chip, 8processors/chip, 16
processors. (aka single e5-2600 has the processor power equivalent of
more than ten max. configured 80processor z196), 33BIPS/processor,
$3.44/BIPS, and $113/processor (compared to 625MIPS, $560,000, and
$350,000 respectively for z196 ... based on $28M ... not fully loaded
$175M ... aka factor 6.25 times).

Assumption that disk technology is effectively the same ... except for
any additional overhead of CKD layer simulation on regular disks for
mainframe (aka CKD disks haven't been manufactured for decades, being
simulated on top of industry standard disks).

from above:
The Intel Xeon processor E5-2600 product family reached a new
supercomputing milestone as the fastest adopted new processing
technology to power 44 systems, including 3 Petascale-class
supercomputers on the 39th edition of the Top500 list announced today.

... snip ...

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

wdonzelli@GMAIL.COM (William Donzelli) writes:
Was this effort in some way related, or in competition with, the UC
series of controllers? Quite a lot of machines used those internally,
and they even popped out with the 8100 series (the mainframes that
have fallen into the memory hole).

uc controllers were much simpler, earlier (and underpowered)
processors, 3705, 8100, service processor for 3081, etc. early on
before 3705 was announced there was a strong effort at the science
center to get cpd to use peachtree for 3705 (instead of uc)
... peachtree was much more powerful processor and was used in
series/1.

UCs would have been part of the internal microprocessors replaced by
801, the 801 replacement effort was circa 1980 ... but for various
reasons the efforts floundered (the as/400 quickly did a cisc chip to
replace the planned 801 ... but in the 90s eventually migrated to
801/risc power/pc). The followon to 4331/4341 (aka 4361/4381) were
suppose to be iliad (801/risc) ... but there was a white paper (that I
contributed to) that shot down that effort (even tho I was working on
801/risc for other things). In the wake of the failure of those
efforts in the earlier 80s, some number of 801/risc chip engineers
left and showup working on risc efforts at other vendors (I've posted
various old email from people worried that I might be following in
their footsteps).

bo evans had asked my wife to audit 8100 and shortly later it was
effectively canceled (although continued to linger on for quite some
time) ... has some amount about UC also:
https://en.wikipedia.org/wiki/IBM_8100

later one of the baby bells did a NCP & VTAM (both) emulation on
series/1 ... and outboard of mainframe ... carried sna traffic over real
networking infrastructure (mainframe vtams were told all resources were
cross-domain ... which was actually simulated outboard in redundant
infrastructure). I did a deal with the baby bell to turn it out as an
IBM product ... as well as concurrently porting from series/1 to rios
(801/risc processor used in rs/6000). Because I knew that communication
group would be out for my head ... I cut a deal with another baby bell
to underwrite all of my development costs ... with no strings attached
(their business case was that they would totally recover all my costs
within the first year just replacing 37x5/NCP with new product). The
internal politics that then happened could only be described as truth is
stranger than fiction.

In the previous reference about using large number of 370 3mip roman
(three) chip sets in racks ... the 801 chip was blue iliad ... which was
first 32bit 801 chip ... and design for 20mips ... although it was never
put into production (and it was a very large "hot" chip). Biggest design
problem & bottleneck was increasing problem with getting all the heat
out of the rack as ever increasing numbers of chips were packed into the
rack. old post
http://www.garlic.com/~lynn/2004m.html#17 mainframe and microprocessors

there was huge amount of communication group FUD about my 3725 numbers
used in comparison/presentation ... which I pulled directly from HONE
3725 "configurator" ... HONE configurations (world-wide virtual machine
based online sales&marketing) were used by IBM sales&marketing for
configuring hardware. In the case of 3725 configurator ... performance
modeling had official communication group sanction. misc. past posts
mentioning HONE
http://www.garlic.com/~lynn/subtopic.html#hone

one of my hobbies was enhanced production operating systems for internal
datacenters ... HONE was (also) one of my long time customers since
cp67/cms days in the early 70s. that hone was actually virtual machine
based was obfuscated from most field people. There would periodically be
branch manager promoted into hdqtr executive position ... that included
HONE ... and would be horrified to find out that it was all virtual
machine based and not MVS. They would figure that they could make their
career & repudiation in the company by migrating HONE to MVS. All the
resources of HONE would be dedicated for several months on a MVS
migration until it was evident that it wouldn't work. Things would be
quietly covered up until the next branch manager promoted into the
executive position (and an attempt at another disasterous port was
made). Finally they took to threatening HONE with they had to stop
using my enhanced operating systems ... because what would happen if I
was hit by a bus.

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

72 column cards

recent thread in another fora about ancient times was discussion why ibm
36bit computers with column binary was 72 columns ... that 72 columns
was plug-board limit ... which was almost always the first 72
... leaving the last 8 for sequence numbers for when you dropped the
deck.

jmfbahciv <See.above@aol.com> writes:
The how did we get stuck with Obamacare? How did the banks and
auto makers get trillions of dollars with not many strings attached?
How did a close to a trillion get disbursed for "so-called"
infrastructure improvements?

it had started earlier in 2002 when congress let the fiscal
responsibility act expire (spending had to be matched by tax revenue).
CBO had report that last decade, tax revenue was reduced by $6T and
spending increased by $6T for $12T budget gap (compared to baseline
which had all federal debt retired by 2010). in the middle of last
decade, congressional budget craziness was so bad that comptroller
general would make references in speeches that nobody in congress was
capable of middle school arithmetic. the tax cuts and large increase in
size of gov. last decade have a momentum that carries forward ... like
getting oil super-tanker to change direction.

dwarfing health care act (which CBO has overall positive effect) was
medicare part-d ... first major legislation after fiscal responsibility act was allowed to expire. comptroller general characterizes it as
long-term $40T unfunded mandate that comes to dwarf all other items. cbs
60mins did expose ... characterizing as trillions of dollars gift to the
drug industry. 18 staffers and members of congress (from party in power)
were responsible for shepherding bill thru ... at last minute they
insert sentence prohibiting competitive bidding and prevent CBO from
distributed report as to the effect of that sentence, until after the
vote. After the legislation passes, all 18 resign and are on drug
industry payrolls. 60mins shows table of identical drugs from Veterns
administration (which has competitive bidding) and medicare part-d ...
with the drugs under part-d three times the price of the same drugs from
VA.

there have been recent news items on both "how 'clinton' balanced budget
was bad for the country" and "how drug competitive bidding is bad for
the country". somewhat brings to mind all the fraudulent news reports
and testimony before congress (paid for by the tobacco industry) about
how smoking cigarettes wasn't bad for the country. this morning there
was item on science article recently picked up by several news
operations about how there was no statistical difference between organic
and non-organic food. the item this morning is that the author of the
science article is funded by the large agricultural corporations and
that the author was also one of the tobacco industry paid experts
testifying before congress about how there was no statiscal evidence
that smoking cigarettes was bad for people.

this has the problems much more systemic and long-term (reference ny
times article from last sept.).

In 1995, the Big Six -- JPMorgan, Bank of America Corp., Citigroup
Inc., Wells Fargo & Co., Goldman Sachs Group Inc. and Morgan Stanley
-- had assets worth only 17 percent of U.S. gross domestic product. As
recently as 2005, their collective balance sheets were valued at less
than 50 percent of GDP.

Today, the Big Six are much bigger, with combined assets of 60 percent
of GDP.

... snip ...

... however there was article yesterday that just the big five (w/o
morgan stanley) are 56% of GDP.

past relatively modest-size there is to benefit to the economy, society,
and/or country of larger sized institutions ... and the TBTF were large
part responsible for the economic mess of the last decade (not only
taking down the economy, nearly taking down the country and the world)
and continue to represent enormous systemic risk.

Etymology of APAR

jwglists@GMAIL.COM (John Gilmore) writes:
Did the phrase come first, followed by its acronym? Or did the
acronym come first, followed by the construction of a more or, often,
very much less felicitous phrase to serve as its imputed its origin?

aka some claims that spool comes from spool/reel of tape which came from
spools in looms ... which then generates phrase (unit-record front-end
done by manually moving tapes between the backend processor and the
front-end handling unit record).

from science center ... GML were the initials of the three people that
invented GML at the science center in 1969 ... then needed to come up
with the phrase generalized markup language.

also from science center ... charlie invented compare&swap while working
on fine grain locking on cp67 multiprocessor. CAS are his initials which
then resultetd in compare&swap. initial attempt to get compare&swap
added to 370 was rebuffed, the 370 architecture owners saying that the
POK favorite son operating system people claimed that (360) test&set was
sufficient. the challenge from the 370 architecture owners was to come
up with a non-multiprocessor specific use for compare&swap. thus was
born the examples (that still appear in principles of operation) for
using compare&swap in multithreaded/multiprogramming applications
(independent of whether running on single processor or multiple
processors). compare&swap was so useful that in the 80s it shows up on
many other processor architecture and used by just about all large,
high-thruput, DBMS implementations.

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

note part of the enormous growth in servers was that they were viewed
as nearly zero cost item ... so people costs to manage multiple
applications was greater than just having server per application. some
operations then found that that they might have grown to hundreds of
thousands of servers ... and that the provisioning became a single
large budget item (but still less than traditional people costs of
manage multiple applications per server). Note that this is different
than the cloud mega-datacenters with hundreds of thousands of servers
... which developed their own RAS, management & adminstsrative
strategy ... and actual have processor use that justifies the hundreds
of thousands of servers (and millions of processors).

vmware (and others) move into the market using virtual machines
to drastically reduce the cost of managing multiple applications per
server ... they were claiming 10:1 server consolidation for the
previous generation over the generation before that.

at the current moment, following appears to incorrectly copy the
description of HS23E for e5-2400 which is single chip-socket ... the
HS23 is e5-2600 with dual chip-socket with 8processor per chip, for
16processors and 32 hyperthreads.

that could allow four bladecenter h chassis (36U) per 42U rack or 56
HS23 blades, @$1815 is $101,640 (plus cost of rack and four bladecenter
H chassis) and at 527BIPS would be aggregate of 30TIPS (or equivalent of
590 50MIP 80-processor z196 and @$28M would be $16.5B, IBM uplift for
mainframe for services, software, and storage would be over $100B ).

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

PDP-10 system calls, was 1132 printer history

Peter Flass <Peter_Flass@Yahoo.com> writes:
I remember for the /30 you had to IPL a special deck. I thought it
was a microcode load, but IBM calls it an "Initialization Deck" and
doesn't give any more information.

this previous thread discusses whether the 1401 microcode emulation was
switch on the front panel or a diagnose instruction ... which would have
required some 360 software to execute the diagnose instruction ... a
small number of instruction on cards would have executed the instruction
(and front panel system reset button would have brought things back to
"normal" operation).
http://www.garlic.com/~lynn/2011h.html#15 Is the magic and romance killed by Windows (and Linux)?
http://www.garlic.com/~lynn/2011h.html#16 Is the magic and romance killed by Windows (and Linux)?
http://www.garlic.com/~lynn/2011h.html#18 Is the magic and romance killed by Windows (and Linux)?

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

there were two different scenarios ... the large proliferation of i86
servers with very low processor utilization being able to leverage
virtual machines to consolidate 10:1 ... even using the same hardware
(i.e. being able to consolidate ten 10% utilized systems into a single
system ... w/o changing hardware). In the middle of last decade Marines
were talking about 10:1 consolidation of datacenters (each datacenter
with approx. same number of servers ... using virtual machines to
eliminate 90% of the datacenters ... with their servers typically avg.
10% cpu utilization).

from above, Intel core2 dual-core as recently as 2006 was 27BIPS.
e5-2600 (@527BIPS) would be able to consolidate 20 such systems all
avg. nearly 100% processor utilization (potentially even w/o
virtualization ... if originally replicated running same application).

the 2006 core2 dual-core was 13BIPS/core ... compared to e6-2600
@527BIPS and 16cores is 33BIPS/core. 2.5 times per core performance
increase over approx. five years but also four times the cores/chip
gives factor of aggregate ten times increase per chip in five years
... and then two chips to give the 20:1. as per previous posts, e5-2600
@527BIPS is equivalent of 10.5 maxed out, 80-processor, 50BIP z196 or
seven maxed out, 101-processor 75BIPS zEC12 (z196 core is 50/80 or
624MIPS and zEC12 core is 75/101 or 743MIPS).

moore's law doubling every 18months hit single processor thruput
increase limits sometime ago ... this old thread quotes intels svp pat
gelsinger having to explain the realities to the CEO of microsoft and
need to adopt parallel programming in order to take avantage of further
thruput increases:
http://www.garlic.com/~lynn/2008f.html#42 Panic in Multicore Land

IBM had somewhat similar moment with 3081 ... which originally wasn't
going to have a single processor version ... but there was issue with
ACP/TPF not having (tightly-coupled) multiprocessor support (ACP/TPF had
loosely-coupled support from early days in 60s) and the major clone
vendor still offering faster single processor machine (potential that
all the ACP/TPF customers would migrate to clone vendor). Initially
there were all sorts of unnatural acts to try and make 3081 attractive
to ACP/TPF customers ... but finally a 3083 had to be offerred by
removing one of the processor from 3081 (there were some physical issues
since 3081 processor0 was at the top of the box ... and it would have
been more of a no brainer to remove processor1 in the middle of the box
... but that would have left the box dangerously top-heavy).

of course the 3081 also had lots of other issues ... one of the
quick&dirty efforts launched after failure of future system (FS internal
politics actively killing off all the 370 efforts ... lack of 370
products also allowed the clone processor vendors to gain market
foothold). misc. past posts mentioning Future System
http://www.garlic.com/~lynn/submain.html#futuresys

from above:
What determines whether you deal with new situations in a flexible
manner or simply act out of habit? A team of psychologists have
discovered that this is predicted by the strength of specific
connections in the brain. It can therefore be seen in your brain
whether you act consciously or on automatic pilot. An understanding of
this is relevant for the treatment of drug addicts and compulsive
patients, for example.

... snip ....

There has got to be lots of levels related to serial/parallel. Boyd's
dog fights have lots of visual parallel ... and he objected to
original heads-up display in f16 which had scrolling digital numbers
.... claiming the mental effort to translate digital number into
useful information took away from efficiently flying. The other part
is great difficulty for those predisposed to automatic have a great
deal of trouble unlearning the behavior when it is no longer useful
(and/or even detrimental).

Parallel for computer programming has been holy grail for long time
... increasingly with transition to multiple core chips. Traditional
programming tools are serial/sequential one step at a time ... there
is corresponding issue that the brain world view becomes conditioned
by the tools it has available; aka serial/sequential digital tools
tends to reinforce serial/sequential thinking. old post about Intel
SVP having to explain to Microsoft CEO that they would have to start
adopting parallel programming paradigm
http://www.garlic.com/~lynn/2008f.html#2 Panic in Multicore Land

There is whether there is established status quo and vested interests
or not.

We were brought in as consultants to small client/server startup that
wanted to do payment transactions on their server ... the startup had
also invented some technology they called "SSL" they wanted to use
... the result is now frequently called "electronic commerce". Since
that time, there has been dozens of things created that address
serious deficiencies in SSL ... but none of them have managed to
displace the incumbent (disclaimer: we have a couple dozen patents in
the area). Fast uptake of SSL mode of electronic commerce was because
there wasn't established incumbent ... but once something is
established ... it is much harder to replace.

Note: about same time peter published his CACM working set paper in
1968 ... I was doing something similar but different. Didn't try to
make it an academic issue ... but just got it incorporated in
commercial products. In the early 80s there was somebody had done his
PHD at Stanford on something similar to what I had done as
undergraduate in the 60s ... which was in many ways directly
contradicted Peter's work. Peter was lobbying hard to prevent Stanford
from awarding the PHD (which contradicted his work from the 60s). I
got dragged into the dustup since I had apples-to-apples comparison
between the two different kinds of implementations on identical
software & hardware. recent discussion here:
http://www.garlic.com/~lynn/2012l.html#37

There is all sorts of pressures and vested interests related to
maintaining the incumbent, status-quo, etc.

another aspect ... whether something new is viewed as a cost or a
profit:

If you are in the business selling works ... then the equipment to
read the works can represent cost item ... and higher cost represents
barrier to selling works (the old "give away the razor to sell razor
blades"). I once got into dustup with GSA over the chips being used in
CAC-card ... vendors of existing chips viewing it as profit item
... and I was looking at designing chip from standpoint of it being a
cost item (optimizing design to reduce costs as opposed to designing
to maximize profit, i even showed how design to reduce costs improved
security ... since design to maximize profit was overly complex)

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

Quadibloc <jsavard@ecn.ab.ca> writes:
All the early IBM 360 computers featured, in one corner of the front
panel, three knobs with hex digits on them with a pattern of buttons
above and below.

That was one of the few parts of the front panel that was for the use
of machine operators instead of IBM service personnel. You turned the
three knobs to choose the boot device, and then you pressed the IPL
(Initial Program Load) to start the computer - you might boot it from
cards, or tape, or disk. It didn't try scanning through them in an
order set from the console screen, the way a modern PC does, but it
did have a boot program of sorts in ROM, so that never had to be
toggled in from the front panel.

aka the IPL button would invoke a "02" channel command read for 24 bytes
into location zero ... and assumed that the first 16 bytes (at location)
zero were additional channel i/o commands and do a channel program
transfer/tic to location zero. when the channel program ended, it would
do a load psw from location 16 (the 3rd double word read).

a three card loader program was first card with 24 bytes that had two
read ccws of 80bytes each (160 bytes) followed by a psw that started
executing at the first byte of the card image read. the 160 bytes was
enough for 40 4byte instructions which were a program to read additional
information.

a more complex disk ipl would be have the first ccw (loaded at location
zero) a read from the disk of additional channel program and the 2nd ccw
a transfer/tic to the channel I/O commands just read ... which could
read a much large program from disk before finishing ... leading to the
LPSW at location 16 ... starting the program.

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

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
Since I just posted something different, I had to look it up to be sure.

The CCWs are from locations 8 and 16, and the PSW in location 0.

The description is "as if" the IPL CCW doing the 24 byte read was
in location zero, though as far as I know, no machines actually do that.
If one did, it would naturally go to location 8 for the next CCW,
after the read overwrites the CCW in location zero.

Somehow it always seemed more natural to me that the PSW came from
location zero.

there was also "restart" button on front panel. if something was going
wrong in the system ... it was possible to hit the restart button
... and it would store the current psw at location 8 and load the new
psw from location zero (in much the same way that IPL would load new psw
from location zero after initial i/o)

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

I shudder to recall a time when operating an IBM 370, with an
exitable supervisor of Italian extraction - in London, England.

A trick that could on occasion be useful, was to hit STOP.
Maybe to clear some device problem - without the CPU spitting out
console errors. Or use the switches to change the system clock - etc.
And them hit RESTART.

One day I pressed STOP to show this to a fellow operator. The
supervisor, from outside the ops room, saw all the lights had frozen
and came running in a panicked state. So I just pressed RESTART. If
looks could kill, you would not have read this.

One of the scenarios was that the west was suppose to exhaust itself
in the retaliation efforts. Instead of quick reaction attack on those
responsible ... there was marshaling of massive forces that allows
time for Al Qaeda to melt way ... long before any strike was
made. MICC takes advantage of the situation to turn it into several
trillion dollar campaign against Iraq and Taliban. Does it repeat
Vietnam because MICC can never learn ... or does it repeat Vietnam
because MICC is preoccupied with having continuous conflict and
perpetual war.

There was the farce a few months in when there were eyes on the target
and they couldn't get approval to take the shot.

The long-term war bill will supposedly exceed $5T with long-term
health benefits taken into account. However one analysis was that last
decade, DOD got an extra $2T over baseline ... $1T appropriations for
the wars and not able to demonstrate what DOD got for the other
trillion. CBO has last decade there being a $6T reduction in tax
revenue and $6T increase in spending (compared to baseline) for $12T
budget gap. Unknown what part of the other $4T increase in spending
(over baseline) disappeared into non-DOD MICC related activities
(including things like the $16B in shrink wrapped $100 bills sent over
on pallets that apparently disappeared in Iraq). Is this failure to
learn and/or "perpetual war" strategy?

from above:
Osama bin Laden repeatedly said that his strategy for defeating the US
and driving it out of the Middle East was to bankrupt the US by
suckering it into a string expensive of never ending small wars. Osama
may be dead, but the US remains locked in a state of perpetual wars
abroad and shrinking civil liberties at home.

hancock4 writes:
I understand on 1401's it was common for a customer programmer to take
control of a machine and step through his program logic using the
console lights and switches. But the 1401 instruction set was
relatively simple and there was no supervisor or operating system to
get in the way.

Was it common for a typical customer programmer to operate S/360 from
the console, step-by-step? I assume that would've been more tricky
due to the complexity of the S/360 instruction set and the need to
work with the supervisor for I/O calls and interrupts.

univ had 709 with 1401 front-end handling unit record (operator moved
tapes between 709 and 1401). then they were to get 360/67 running
tss/360 to replace everything. as part of transition they got 360/30 to
replace 1401 ... it would run unit record front-end MPIO natively
... but I got a student job to write a 360 native replacement
(performing all the 1401 MPIO unit record).

They normally shutdown on the weekends ... and let me have the
datacenter from 8am Saturday until 8am Monday. My MPIO replacement
eventually grew to box (2000) of cards. It had assembler conditional
that would either generate a stand-alone monitor (had my own interrupt
handler, device drivers, error recovery, storage management, dispatcher,
etc) or run under os/360 (open/close, get/put, dcb macros). Stand-alone
version would assemble in under 30 minutes (circa os/360 pcp release 6
on 360/30). os/360 version took approx. an hour to assemble ... could
watch it take approx. 5-6 minutes each for DCB macro.

Debugging program on weekends, I spent a lot of time with switches. You
could set address in switches and set rotary switch for
address-compare-stop ... and then single step the machine, one
instruction at a time. Toggles could be used to display values in
storage or registers. It was also possible to use toggles to modify
values.

The output of the stand-alone version ... would slap the BCP stand-alone
loader on the front and boot from the card reader (similar to 1401 MPIO
boot).

Later the 709 and 360/30 was replaced with 360/67 but tss/360 never got
very mature. I was then hired for supporting os/360 ... and would still
usually get the datacenter for the weekend (I've mentioned before that
being up for 48hrs made monday morning classes a challenge).

came out last week jan, 1969 to install cp67. I then got to play with
cp67 and os/360 on weekends ... however, cp67 never quite got to the
place that univ. did regular production during the week.

the installed cp67 had image restore to 2314 (with cp67 boot and cms and
other file areas) and cp67 source files assembled under os/360 (just
before they moved cp67 source maintenance to cms). Output of all cp67
source assemblies fit in card tray (i.e. less than 3000 cards but more
than 2000 card box). Each module deck would have magic marker diagonal
stripe with abbreviated name of module across top of deck ... making it
easy to replace individual module executable deck. At the front of the
CP67 load deck tray was the BPS stand-alone loader.

To build a new CP67 required doing stand-alone load of the card deck,
which would load an image of the CP67 into kernel ... and transfer to
entry point in "CPINIT" routine. CPINIT would write a memory image of
the kernel to indicated disk position and update disk IPL information
... to load CPINIT. Standard system IPL from disk would bring in CPINIT
... which would reverse the process of writing the memory image to disk
... substituting read for write.

After CP67 source maintenance was moved to CMS ... there was also change
to virutal machine operation ... "punching" the executable kernel cards
to the virtual punch device ... which was "transferred" transferred to
the virtual card reader device and a virtual IPL performance. Would have
a virtual disk definition that mapped to the production real disk ... so
the CPINIT kernel memory image write ... would overlay the real bootable
kernel.

Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid> writes:
There is no "the IBM 370 control panel"; each model had its own. In
particular, some older models had rollers and some newer models droped
them in favor of other techniques.

transition from front panel to keyboard/display-screen.

before announce of virtual memory for 370, a copy of virtual memory
hardcopy document showed up at some industry publication. there was then
a "pentagon paper" witchhunt for the leak. best they could do was
suspect the leak came from somebody in the vm370 development group (was
still on 3rd flr of 545 tech sq after having taken over the ibm boston
programming center). in the aftermath of the witchhunt, all corporate
copy machines were retrofitted with unique serial number under the glass
... that would appear on all copied pages. more than decade later can be
seen in this copy made on copy macine in IBM San Jose Research
http://www.garlic.com/~lynn/grayft84.pdf

For the FS effort ... the VM370 group had done a super-secure vm370 used
for reading softcopy future system document (with facilities inhibited
for any spool-file/print capacility ... or doing anything but softcopy
reading). By this time, they had moved out to the former (vacated) SBC
bldg in Burlington Mall (SBC gone to CDC as part of some legal action).
http://www.garlic.com/~lynn/submain.html#futuresys

I had some machine time on 370/145 in their machine room over the
weekend ... in support of this ECPS activity that I had been con'ed
into doing:
http://www.garlic.com/~lynn/94.html#21 370 ECPS VM microcode assist

I stopped by late Friday afternoon, as part of setting up for weekend
machine use, they showed me their 370/155 with all the FS enhancements
and said that even I (aka lynn) couldn't break the security. I guess I
succumbed to temptation and said that it would take less than five
minutes. Most of the time was taken disabling all external access to the
370/155 and then I used the front panel to patch a byte in storage
... which change branch on condition instruction ... so that
everything/whatever typed in was taken as valid password. I pointed out
that for somebody with physical access they needed either a method for
securing front panel and/or encryption for the data.

Later machines allowed for "logon" password for using the machine
functions ... like display/alter storage.

field service had procedure requiring to bootstrap machine starting with
scope. TCMs introduced with 3081 were totally enclosed and didn't allow
for scoping. for field service, a bootstrap process was introduced with
service processor that could be scoped/diagnosed ... and then using the
service processor that had all sorts of diagnostic instrumentation into
the TCMs. The service processor then also supported all the other
machine functions. The problem was that uc processor was primitive and a
whole monitor and infrastructure had to be developed for scratch for the
machine.

This was going to be changed for the 3090 followon ... where vm370/cms
running on 4331 would be used instead as a base for building service
processor. This was eventually changed to instead have a pair of
redundant 4361s ... but still running vm370/cms ... with service
processor functions implemented with cms ios3270.

Clark Morris <cfmpublic@ns.sympatico.ca> writes:
I see what you have posted and what Lynn Wheeler has posted and am
confused. Assuming that VMware on Intel and similar solutions for the
p series have gotten much better since 2007 (not unrealistic), I'm
looking at the relative CPU power and asking is the server utilization
in a well run Intel (Windows and Linux) or IBM p series shop still so
low that z can beat them on a total dollars out the door. Is the main
difference the I-O handling?

note that disks will be the same across the three technologies, however
i86 and risc will frequently have an edge over mainframe w/o the
overhead of the additional layer to simulate CKD (ckd disks haven't been
manufactured for decades, being emulated on industry standard disks).