Re: OT (Maybe): ERPs

From: Robert Wagner (spamblocker-robert_at_wagner.net)
Date: 01/28/05 

Date: Fri, 28 Jan 2005 03:39:18 GMT

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?

Relevant Pages

  • Re: got very slow
    ... - Uninstalled unknown/unneeded applications in Add/Remove Programs? ... What hardware do you have? ... What to Know Before You Download and Install Windows XP Service Pack 2 ... You also have hardware on your machine that requires drivers to interface ...
    (microsoft.public.windowsxp.general)
  • Re: OT: Re: Jobst Brandt vs. Tire Glue
    ... The winning combination was generic hardware and bundled software. ... in the sense that they are server apps that don't have to deal with a plethora of peripherals and are singular applications that don't have to integrate with a lot of others. ... Who would put up somebody with a stutter as a presenter? ...
    (rec.bicycles.tech)
  • Re: Is Linux A Feasible Platofrm For Professional DAW work ?
    ... RME devices accept only 24-in-32 bit sample format in non-interleaved ... have a 16 bit audio file and you attempt to configure the RME hardware ... For many applications, particularly desktop/consumer media ... quality SRC intervening between it and the hardware. ...
    (rec.audio.pro)
  • Re: Limitations of VMs?
    ... Would anyone with direct experience of working with VMs like to comment on this review and/or on the limitations of other VM products? ... Memory or data Intensive applications and/or critical applications can have their own OS dedicated to that one application. ... No other applications outside applications that would normally running on a single instance server. ... Consolidation of Hardware: Instead of 5 servers, each with an OS, you can choose to buy one redundant server with multiple CPUs and lots of RAM and create VMs based upon need on that one box. ...
    (borland.public.delphi.non-technical)
  • Re: Announce: Impulse C-to-RTL Version 2 now available
    ... is a useful replacement for VHDL and/or Verilog programming. ... There is also little benefit in doing "baby applications" ... hardware equivalents or pre-optimized library blocks ... HDL programming. ...
    (comp.arch.fpga)