Re: OT (Maybe): ERPs

Define success.
* Is it the actual implementation and users using the new system?
* Is it that the end users actually like the new system and its
functioning?
* Is it that the DR/Plan can be tested and things work at the DR site?

Or, in the case of a certain Electric Utility (those folks that are
said to have brought you the NE power outage) is it that upper
management declared the new system to be a success regardless of what
the end users were complaining about?

The problem boils down to not being able to do all of the I/Os needed
for an application system. When you have to have one system running the
database, another running the web server, yet another running the
applications and they all have to communicate across the same network,
what do you think happens next? Add to this all the I/O that must be
done by each of those "hosts" for system servicing, and local file
processing.

Take any mainframe (Honeywell, IBM, Unisys, etc.) and look at how they
are able to run all of those functions within the same box. The
critical interprocess communications I/O is done within memory at
memory access speeds. The only physical I/O that needs be done in this
case is local file servcie I/O, data base I/O, O/S and communications
I/O with/to the end users. And all of those are basically done with
TRUE Parallel processes.
To that end me thinks your statistics are very skewed.

Steve.T

On 26 Jan 2005 12:21:11 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>Define success.
>* Is it the actual implementation and users using the new system?
>* Is it that the end users actually like the new system and its
>functioning?
>* Is it that the DR/Plan can be tested and things work at the DR site?

It was just a customer count. No doubt a small percentage bought the
thing and never installed it. A comparable  small percentage of
mainframes are gathering dust. Neither alters the macroscopic fact
that there are more ERP customers than mainframe customers (the number
of shops/installations would be larger for both).

>Or, in the case of a certain Electric Utility (those folks that are
>said to have brought you the NE power outage) is it that upper
>management declared the new system to be a success regardless of what
>the end users were complaining about?

That's been happening in mainframe shops for 40+ years. Technology
doesn't change human nature.

>The problem boils down to not being able to do all of the I/Os needed
>for an application system. When you have to have one system running the
>database, another running the web server, yet another running the
>applications and they all have to communicate across the same network,
>what do you think happens next? Add to this all the I/O that must be
>done by each of those "hosts" for system servicing, and local file
>processing.

Mainframes also have to transport data from disk drive to CPU memory.
IBM's ESCON, which runs at 200mb/s, is slower than 2gb/s Fibre Channel
and 1.3gb/s SCSI-3.

>Take any mainframe (Honeywell, IBM, Unisys, etc.)

Honeywell stopped making or selling computers in 1991.

> and look at how they
>are able to run all of those functions within the same box. The
>critical interprocess communications I/O is done within memory at
>memory access speeds. The only physical I/O that needs be done in this
>case is local file servcie I/O, data base I/O, O/S and communications
>I/O with/to the end users. And all of those are basically done with
>TRUE Parallel processes.

Unix and Windows boxes also have multiple CPUs and pass data between
them at memory speed. Google on IPC (InterProcess Communication).

To evaluate OLTP thruput, for example, a top-down measurement of
actual performance is more informative than bottom-up hand waving
about channel speed and the like. When Unix systems are configured by
professionals, as opposed to non-technical management, they deliver
about the same performance as mainframes for a fraction of the cost.

Benchmark speed and cost per transaction data is publically available
for hundreds of platforms. Why are mainframes conspicuously absent?
Because they can't compete on cost.

>To that end me thinks your statistics are very skewed.

Kindly supply corrected statistics on number of ERP and mainframe
customers, or shops, or users.

While you're at it, explain why most mainframe growth in the last ten
years involved Linux and Web serving .. both ideas borrowed from other
cultures.

On 26 Jan 2005 20:19:43 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>Robert:
>
>Define success rather than deflecting.

A successful platform conversion is one where the organization ceases
being a user of the old platform, for the application(s) in question,
and becomes a 'permanent' user of the new platform.

It's not my definition; it comes from the worlds of investment and
marketing.

>Next, if you want to argue architecture, I'm ready. Be forwarned that I
>have other than mainframes in my tool box and that I actually have
>written microcode.

Your arguments for the superiority of mainframes are bottom-up. The
business world cited above looks at it top-down.

For instance, you think mainframes are 'inherently superior' for OLTP
because of channel design and operating system architecture. The
decision-making executive says, 'Don't tell me about technical
details. Run the same transactions through both, then tell me response
times and cost per transaction.' When the mainframe loses, you'll
claim the other side cheated by using a larger than normal cache or by
locking programs in memory. You'll be incapible of disengaging
bottom-up, incapible of thinking like the executive.

>Come to think of it, didn't you kinda get into this with me about 2
>years ago when I was too busy to engage you in your drivel?

I don't recall but it's likely that happened.

>But then,
>what with me being in the industry for over 30 years, maybe I'm having
>another of those senior moments.

If longevity were the only criterion, I'd win.

Lessons learned 30 years ago, when hardware was expensive, no longer
apply in today's world of cheap hardware. Worse, insisting on their
application can be counter-productive. Calcified thinking is WHY they
retire old farts. (Present company excluded, of course.)

Robert Wagner wrote:
>
>
> If longevity were the only criterion, I'd win.
>
> Lessons learned 30 years ago, when hardware was expensive, no longer
> apply in today's world of cheap hardware. Worse, insisting on their
> application can be counter-productive. Calcified thinking is WHY they
> retire old farts. (Present company excluded, of course.)

That's rather too broad a generalization, I'd say.  Lessons learned 30
years ago about using minimum resources, about making sure that
un-necessary statements stay outside the perform loops, things like that
- still are useful and will make for better programming.

I'm sure you didn't mean to imply this, but there are those who would
interpret your statement as meaning "it doesn't matter if we write
horrible inefficient programs that use a hundred times the memory and
disk space they actually need becuase hardware is so fast and cheap that
nobody will ever notice, just as long as they work, somehow".  Did you
ever see the flight simulator hidden away as an easter egg in EXCEL?

Didn't structured programming come into existence about 30 years ago?

PL

On 27 Jan 2005 08:20:07 -0800, "steve.t" <sthompson@ix.netcom.com>
wrote:

>For instance, in our facilities here, where I make the decisions as to
>what hardware, O/S, etc, we run all Intel based systems. We are
>currently running NT 4.0 workstations because they do the job.

"Do the job" is as amorphous as "successful". A rock can do the job of
a hammer.

>We see no reason to migrate to anything Micro$**t offers.

No sign of bias there.

>As a result, we are
>going to migrate to Linux as soon as we solve certain of our backup
>issues. Sun Office does everything we need, so good riddance to
>MS/Office.

Quoting from the Wine Web site:

"The dependency is not so much on Microsoft Windows as it is on
Windows applications. Boxed off-the-shelf applications, games,
in-house applications, vertical market applications, are what prevents
users, companies and governments from switching to another operating
system. Even if 90% of the needs of most users are taken care of if
you can provide them with an office suite, an email client, a browser,
and a media player, then there will still be a remaining 10% of their
needs, potentially critical needs, that are not met. Unfortunately
these remaining 10% are spread across a wide spectrum of applications:
thousands of applications running the gamut from games to specialized
accounting software for French farms, via Italian encyclopedias,
German tax software, child education software, banking software,
in-house software representing years of development, etc. It is the
availability of all this software that makes Windows so compelling and
its monopoly so strong. No platform will become mainstream unless it
runs a significant portion of that software and lets individuals,
companies and governments preserve their investments in that
software."
http://www.winehq.com/site/why

Lacking Wine or equivalent, you've locked your users into in-house
developed software. That's what most IT administrators want, but is
not what users want.

>When you discuss OLTP tests you do realize that there is more to it
>than just running a screen write/read and grab a line from a table. So
>when the computations are done for cost per transaction, the models
>given do not necessarily meet what a business actually does. All they
>do is tell us what a specific configuration can do with a standard
>test. It gives us the ability to compare apples to apples, sort of.

The benchmarks are designed to model 'typical' applications. They do
more than a screen write/read followed by grab a line.

"TPC benchmarks also differ from other benchmarks in that TPC
benchmarks are modeled after actual production applications and
environments rather than stand-alone computer tests which may not
evaluate key performance factors like user interface, communications,
disk I/Os, data storage, and backup and recovery.

The most frequent transaction consists of entering a new order which,
on average, is comprised of ten different items. Each warehouse tries
to maintain stock for the 100,000 items in the Company's catalog and
fill orders from that stock. However, in reality, one warehouse will
probably not have all the parts required to fill every order.
Therefore, TPC-C requires that close to ten percent of all orders must
be supplied by another warehouse of the Company. Another frequent
transaction consists in recording a payment received from a customer.
Less frequently, operators will request the status of a previously
placed order, process a batch of ten orders for delivery, or query the
system for potential supply shortages by examining the level of stock
at the local warehouse. A total of five types of transactions, then,
are used to model this business activity."
http://www.tpc.org/tpcc/detail.asp

>Can you, Mr. Wagner, tell me how fast an Itanium can process 5TB of
>data v. a S/390 ESA system running OS/390 V2R10? Which one will finish
>first? When is a MIP not a MIP? Yet this is the kind of comparision
>that is attempted with OLTP numbers.

The important question, from a management point of view, is how much
it costs to process all the company's transactions.

>Assuming that the one machine has
>8 CPUs and 2GB of memory, can it also be doing a large amount of batch
>oriented processing at the same time and still achieve its OLTP numbers
>(and I was actually thinking of a Regatta runing AIX5L)?

Here you're referring to Total Cost of Ownership. Since most costs are
labor rather than hardware/software, TCO is impossible to measure with
a benchmark. It's a function of management and organization. At first
glance, a centralized mainframe would have the advantage over hundreds
to thousands of decentralized servers. The issue of centralized vs.
decentralized has been examined extensively in the literature of
business. One concern, for example, is acquisitions and spin-offs.
Companaies that are centralized find it difficult to digest an
acquisition and nearly impossible to spin-off a division.

>Success of a migration/implementation: That an entity is up on the new
>platform and the old one is gone does not a successful migration make.
>When 30% of your people are unable to do their job adequately because
>the new system can't produce a report you need in a reasonable time...
>When companies are seeing Cxx being hauled off in chains...

F.U.D.

>Now let us back up many years. Since you are older than me, and an old
>fart (your definition), why did IBM, RCA, Honeywell, GE, Univac, NCR
>and Burroughs select the internal architectures that they did (I refer
>to Ibank/Dbank, memory v. bus centric, single I/O path v. multiple
>channel processors, etc.)? And who ultimately won the battles and why?
>Frankly, from what I know and remember, Burroughs should have beaten
>IBM and the others to a pulp. But they didn't.

I worked extensively on and for Burroughs, Honeywell and RCA. Techie
wisdom at the time held that IBM won because of better marketing;
hardware had nothing to do with it. Personally, I LOVED the CII/Bull
machines marketed by Honeywell as Level-6x. They failed in the US
because few people knew they existed.

>Why did all the other computer makers that got into this around
>1977-1980 decide on bus centric and segmented memory? Why did they have
>to change to the way mainframes looked at memory?
>
>So why is it that all the makers of computer systems today are trying
>to tell us that they are doing xxxx "which is very much like a
>mainframe?"

Marketing? Surely not envy.

>If what you implied (calcified thinking) should be thrown out, why is
>it then, that when I lived in SillyCone valley, did people I knew
>working for an Intel based mother board maker come to me (and I'm no
>great engineer) to ask how to get two CPUs to work together? Why did
>things get changed about the processors to allow them to do interlocked
>updates?

The answer is SMP. But that doesn't address the basic problem of how
to give applications parallelism. They'll be single-threaded so long
as the programming language assumes it's running on a Von Neumann
machine. Some back-door approaches to parallelism are AI, OO and
database.

>And who had 64bit addressing
>functioning and available first? [You might be surprised.]

Apple, running a PowerPC made by IBM?

>Why do you think I do modeling to determine if the design can handle
>the workload being placed on it? It's the same old calcified routines
>that I used to determine if a mainframe system could handle the
>workload.

I had experience with simulations working for Comress on SCERT. It
cost a fortune and didn't work very well. The fallacy, in my opinion,
was trying to solve top-down problems with a bottom-up model. Given
that it didn't work on single-task processors with minimal I/O
parallelism, the same approach doesn't stand a chance in today's
environment. I think benchmarks are the way to go.

>Could my calcified thinking be why EVERYONE of the migrations I've done
>have not only worked, but performed without having to throw more and
>more resources at it?

Congratulations. Did your plan deal with organization of support
staff, or was it only about hardware and software?

On Thu, 27 Jan 2005 12:38:55 -0600, Peter Lacey
<lacey@mb.sympatico.ca> wrote:

>Robert Wagner wrote:
 
>
>That's rather too broad a generalization, I'd say.  Lessons learned 30
>years ago about using minimum resources, about making sure that
>un-necessary statements stay outside the perform loops, things like that
>- still are useful and will make for better programming.

It's now more a question of Art than Necessity.

>I'm sure you didn't mean to imply this, but there are those who would
>interpret your statement as meaning "it doesn't matter if we write
>horrible inefficient programs that use a hundred times the memory and
>disk space they actually need becuase hardware is so fast and cheap that
>nobody will ever notice, just as long as they work, somehow".

That describes most Windows programs. Why does WeatherBug take 6 meg,
and FireFox take 12 meg? I can remember when only monster machines had
16 meg of memory. Now 128 meg isn't enough to run 2-3 simple apps
without thrashing. Serious servers have 16 gigabytes of memory, which
is more than the total DISK space we once had.

Yet, Cobol programmers are still using packed decimal to save space.
The saving is measured in  pennies; the cost to someone trying to
import the file is many hundreds of dollars.

Robert Wagner wrote:

>
> Yet, Cobol programmers are still using packed decimal to save space.

Won't argue with you about that.  I actually lost a conversion job
because I tried to convince her that packed wasn't necessary.

PL

I certainly will NOT speak to other compilers or operating systems, but the 
(or
at least one of the) major reasons that Packed Decimal is used over "display
" on
IBM mainframes - is for performance not to "save space".  Obviously, this do
es
not impact occasionally used data items or non-performance sensitive
applications, but from page 31 of the

"IBM Enterprise COBOL Version 3 Release 1
Performance Tuning"

the following information seems pretty relevant to me (based on actual
performance testing),

"DISPLAY compared to packed decimal (COMP-3)
- using 1 to 6 digits: DISPLAY is 100% slower than packed decimal
- using 7 to 16 digits: DISPLAY is 40% to 70% slower than packed decimal
- using 17 to 18 digits: DISPLAY is 150% to 200% slower than packed
decimal"

There are LOTS of "caveats" to these specific statistics (in the paper) so
"YMMV".

To see this comparison in context (along with other comparisons of different
compiler options, data types, etc), see the full paper from:

http://www-1.ibm.com/support/docvie...uid=swg27001475

--
Bill Klein
wmklein <at> ix.netcom.com
"Peter Lacey" <lacey@mb.sympatico.ca> wrote in message
news:41F9C5AB.F9B8DC2E@mb.sympatico.ca...
> Robert Wagner wrote:
> 
>
> Won't argue with you about that.  I actually lost a conversion job
> because I tried to convince her that packed wasn't necessary.
>
> PL

"steve.t" <sthompson@ix.netcom.com> wrote in message
news:1106842807.711642.135610@z14g2000cwz.googlegroups.com...

> Success of a migration/implementation: That an entity is up on the new
> platform and the old one is gone does not a successful migration make.
> When 30% of your people are unable to do their job adequately because
> the new system can't produce a report you need in a reasonable time...
> When companies are seeing Cxx being hauled off in chains...

The platform is not the hardware...it's the software solution running on
hardware...could be on multiple servers, single server, end user pc
etc...could even be an application running hosted on someone else's
hardware.

I'm sure a significant number of transformations do not fail due to
inadequate hardware for five simple reasons  -

Firstly, the requirements to move come from executives, yet the requirements
for the application come from end users - super users if you want.   The end
users goal - simplify my life - is not the same as the executives - make
this cheaper.

Secondly, the end users are very good at capturing requirements with regards
to "this is what I've wanted for 2 years" but are very poor at capturing
requirement that express "this is what we need now" (they sometime manage to
tell you what they have now which is not the same thing and unfortunately
they seem to forget the things they do that are painless and refer only to
those things that are painful).  They assume that everything they do will be
provided by default so only share the blue sky future. They don't seem to
want to realize that the migration is like the collective bargaining
agreement in american sports - at the end of the contract it goes away and
the negotiation starts from nada.   A transformation project starts with the
end user having NOTHING.

Thirdly, a failure to recognize that the answer is not to transition the
existing solution from one hardware platform to another.  The solution most
likely works, in part, because of the hardware it is running on.  If there
is a cost issue, there are always options to reduce the hardware costs
without changing the solution architecture.  A migration to a new hardware
should be coupled with the need to migrate to a new solution.  This is often
not the case.  The transition is deemed necessary by consultants and IT
branches...its an existence justification. IT departments are now in the new
role of having to provide - and excuse the marketing slang - their own value
proposition.

Fourthly, the time allowed to complete a migration is never sufficient.  I
understand that in some instances the project is canned after 2-3 years, but
the original project plan was I'm sure *not* that large.  It always starts
at 6 months investment and this is just enough time to try and rush in a
"executive demo" without actually considering the solution
ramifications.....then it becomes a we've gone 6 months, we just need 3
more......then you find the mistakes of the first 6 months .....and then you
need just 3 more...until they finally realize that the business is
suffering.

Fifthly, or lastly even, the platform (still software solution) change, but
the roles and function of personel do not.  As the functional role of the
employees does not change, the data cannot be changed significantly, and
therefore not successfully re-architected, and then alas the problems (not
all, but usually the more heinous ones) are also transformed.  It seems that
the data migration plan and the process definitions are the last item to be
discussed on a transition plan ?!  Unfortunately the success of any data
processing area requires accurate data modelling.  Your functional areas are
then are built around the data and not the other way around.   Perhaps what
we miss is that in some instances the pieces of the mainframe solution being
transformed relies in its original form on some high I/O throughput due to
inadequacies in the data model or even poor code.

A great example is at my location before I arrived there was an IMS to DB2
migration.  The old IMS code was rewritten to "work".  It runs like a dog
because it still accesses the data in a hierarchical and not relational way.
We are still finding instances of  open cursor a to get b...open cursor b to
get c ....open cursor c to get the answer....where DB2 could handle this
much more efficiently as a combination of joins.

I am a only a web bigot. I hate any web application that forces me to hit a
"close window" button, or a "back" button or has to warn me with a "don't
hit this button twice" button.

> I have migrated whole accounting systems off to NT from mainframe. It
> worked because the amount of data to be processed was within the
> capablilities of the design and equipment. However, I explained, and it
> was accepted, what their growth path was and how they would know when
> they got there. The amount of transactions to be processed per hour was
> key. All the programming was being done in COBOL.

Ah...now you touch on it...it really isn't a hardware platform issue ...it's
a software platform issue.....only a specific instance of a failed project
knows why the project failed and I'd venture a guess that 75% of projects it
is not the hardware...


JCE

On Fri, 28 Jan 2005 05:54:04 GMT, "William M. Klein"
<wmklein@nospam.netcom.com> wrote:

>I certainly will NOT speak to other compilers or operating systems, but the
 (or
>at least one of the) major reasons that Packed Decimal is used over "displa
y" on
>IBM mainframes - is for performance not to "save space".

IBM and Unisys mainframes support packed decimal hardware
instructions. On Intel, Sun and others, packed decimal is no faster
than display.

On IBM mainframes (don't know about Unisys), converting display to and
from packed is very fast. When I work on mainframes, I put display in
files, packed in working-storage. I do arithmetic in working-storage,
not in the record area.