Cortlandt,
You are incorrect when you said that MANMAN does no transaction logging.
It does partial logging. The "TR" log files as they're known exist in the
MDATABxx groups (manufacturing database) in the MANMAN data account. These
files are numbered TR000000 through TR999999. They contain information
about all inventory transactions. And in the OMAR, AP and GL packages, the
financial transactions are logged to the Image/SQL history database (HISDB)
in the HDATABxx group.
Now, regarding MANMAN's apparent lack of transactional atomicity. This
shortcoming can be corrected fairly simply. Image/SQL has some relatively
new intrinsics, namely DBXBEGIN, DBXEND and DBXUNDO that will provide
logical transaction atomicity to any single or multiple database
appplication. This transaction protection is connected to the XM of the
MPE/iX operating system which will AUTOMATICALLY ROLLBACK any transaction
that was partially completed as a result of a system problem. Be it a lost
connection, loss of power, software crash, etc.
Why doesn't MANMAN or every other application on the HP3000 use this
feature? I don't know, you'll have to ask the vendor. But, this is NOT a
shortcoming of the DBMS or the OS. It's a design choice by the vendor. A
fairly poor choice IMO, but a choice just the same.
Now, just because most RDBMS packages have this transactional feature
"always enabled" does NOT make it or the applications using it superior.
My theory on their choice is that they "know" that most of the underlying
operating systems that the RDBMS run on are inherently unstable so they
better have a way to bail themselves out of a jam or they wouldn't be
selling that RDBMS package very much! Well actually, it's probably because
of the SQL ROLLBACK command. If the RDBMS doesn't keep track of a
transaction, it couldn't roll it back.
Furthermore, I guess that most HP e3000 application vendors haven't gotten
any (enough) complaints from their customers for them to have to "do the
right thing". And as long as MANMAN has been around, there should have
been sufficient opportunity to complain about this apparent shortcoming.
Maybe this little bit of enlightenment will raise MPE/iX and Image/SQL to
the "robust" level. I can only hope so that I can end this thread!
John Hornberger
Sr. Systems Programmer
SPX Corporation
Cortlandt
Wilson To: [log in to unmask]
<cortlandt@COR cc:
TSOFT.COM> Subject: Re: [HP3000-L] HP's
Sent by: Multi-OS strategy includes MPE
HP-3000 (take 2) <very long>
Systems
Discussion
<HP3000-L@RAVE
N.UTC.EDU>
08/22/2000
07:35 PM
Please respond
to Cortlandt
Wilson
John,
I like the HP e3000. I don't like to dwell on the limitations of the
platform. But I believe that exaggerated claims about the platform
do it a diservice. In defense, therefor, of the HP e3000 here goes
...
I believe that professor referred to in your last sentence studied the
errors professionals make when under conditions of perceived threat or
embarrasement. Your reference to him is ironic.
In the computer industry robustness usually refers to the ability to
recover from errors or failures of the hardware or software.
Your first challenge involved running MANMAN software. That software
is not programmed to use transaction logging, strong locking, or
dynamic rollback recovery. The reason usually given for not using
these robustness features is speed. Many, if not most, Image
applications trade off robustness for speed. The robustness of
these applications are compromised. As a consequence of this some
MANMAN users have to perform manual corrections to accounting data in
order to run the month end close. In my limited experience with
custom MANMAN apps is that the robustness features have a noticible
impact on response time.
To compare these compromised applications with more robust ones is
comparing apples to oranges. For this reason, comparisons of
response time and transactional processing rate of typical HP e3000
applications to other applications and systems are highly suspect.
<[log in to unmask]> wrote in message
news:39a2ba55$1_1@skycache-news.fidnet.com...
>
> Cortlandt,
>
> Since you're still taking exception to my use of calling
> the HP e3000 the "most robust OLTP server available" I
> thought I'd clear the air by first stating the commonly
> accepted definitions of what "robust" means. Below is the
> definition and synonyms given for robust directly from
> www.webster.com:
>
>
> Main Entry: ro·bust
> Pronunciation: rO-'b&st, 'rO-(")b&st
> Function: adjective
> Etymology: Latin robustus oaken, strong, from robor-,
> robur oak, strength
> Date: 1549
> 1 a : having or exhibiting strength or vigorous health b
> : having or showing vigor, strength, or firmness <a
> robust debate> <a robust faith> c : strongly formed or
> constructed : STURDY <a robust plastic>
> 2 : ROUGH, RUDE <stories... laden with robust, down-home
> imagery -- Playboy>
> 3 : requiring strength or vigor <robust work>
> 4 : FULL-BODIED <robust coffee>; also : HEARTY <a robust
> dinner>
> 5 : relating to, resembling, or being any of the
> primitive, relatively large, heavyset hominids (genus
> Australopithecus and especially A. robustus and A.
> boisei) characterized especially by heavy molars and
> small incisors adapted to a vegetarian diet -- compare
> GRACILE 3
> synonym see HEALTHY
> - ro·bust·ly adverb
> - ro·bust·ness /-'b&s(t)-n&s, -(")b&s(t)-/ noun
>
> Entry Word: robust
> Function: adjective
> Text: 1
> Synonyms FLOURISHING, booming, prospering, prosperous,
> roaring, thrifty, thriving
> 2
> Synonyms STRONG 3, concentrated, full-bodied, lusty,
> potent
> From the above accepted definitions of the word "robust"
> which applies to computer systems?
> As some real-life evidence to the first definition of
> robust I submit the following:
>
> 1. The system I currently manage is an HP e3000 KS959/300
> with 2GB of RAM and 140GB of disk
> in an EMC Symmetrix array attached through four
> Fast/Wide SCSI channels. This system runs
> multiple images of both GrowthPower and MANMAN that
> takes care of six different
> manufacturing subsidiaries that transact over $500
> million dollars of sales per year on it. That's
> roughly $2 million dollars worth of business every
> business day. In addition to the production
> images, each unit has at least one devlopment/test
> image that runs on this system. I also have a
> full development 4GL environment, EDI, electronic
> forms and RF barcode-entry devices on this
> system. Oh yeah, I have 179 printers attached to
> it, pretty evenly split between DTC attached and
> network attached devices. There are between 450 to
> 480 online users during the peak hours of
> 10:00AM until 4:00PM. According to my Laserrx charts
> these users "enjoy" subsecond response
> time for more than 90% of those hours regardless of
> the workload mix. I've been running with
> this configuration for about 5 years.
>
> Cortlandt, your first challenge is to find me another
> more robust computer system and software
> that will do what these packages are capable of that
> runs on a system that has 3 lowly 100MHz
> 32-bit processors, 2GB of main memory and only 80MB/s
> (peak) of bandwidth to their disk
> subsystem. And deliver subsecond response time more
> than 90% of the time. If you can name a
> system, please do. I'll definitely consider it. If
> you can't name at least one, I guess I've proven my
> point. However, If you can name one (or more)
> systems consider the next challenge.
>
> 2. The same system above is tested for recoverability
> twice a year at my DR provider's location.
> However, my DR provider does not have a system
> identical to mine. So, I say no problem. The
> HP e3000 is binary compatible across its product
> line. I show up at midnight and start my cold
> iron recovery on a four processor 99X system that has
> only 1.5GB of RAM and is attached with
> only two Fast/Wide SCSI channels to an EMC Symmetrix
> array that contains 140GB of disk.
> After loading my CSLT from my home system and
> spending another hour or two at most to
> fix the hardware addresses, map the tape drives, etc.
> and configure the disks into private volume
> sets containing similar space as my home system, I'm
> ready to restore files. Total time to be
> "production-ready" is less than twelve hours. I made
> it under 10 hours the last time I tested
> because the 99X box had two Fast/Wide attached DLT
> 7000's on it. I only have two single-ended
> SCSI attached DLT4000's on my home system.
>
> Cortlandt, your second challenge it to find me a more
> robust system that can recover a similar
> environment as described above using similar RAM
> configurations and disk bandwidth. I'd bet
> based on empirical evidence of the other platforms
> that I share computer room space with that NO
> OTHER computer system will achieve the above results
> in the same amount of elapsed time.
> From experience, I have witnessed Novell, NT, Alpha
> UNIX and IBM mainframe systems that have
> a very difficult time being recovered in 24 hours let
> alone 12 hours. While I struggle with one or
> two third-party vendors on the phone getting license
> keys for my foreign box, the other guys are
> still trying to cobble together a hardware system
> that will allow them to run at all since it's NOT
> exactly the same configuration as their home system.
> OK, maybe you even cleared this hurdle,
> then try the following challenge.
>
> 3. Come into work on wednesday morning to learn that one
> of your business units had acquired a new
> business that runs on an old 9X7 box that hasn't been
> on maintenance of any kind for the last 5
> years. Then, you learn that this system had been
> banded to a wooden pallet with NO padding
> whatsoever, and trucked clear across the country from
> Silicon Valley to southern Maine in the
> middle of the winter. Next, you learn that it was
> "accidentally" left in the warehouse loading dock
> area for the last 3-4 weeks. You're told that this
> system MUST BE up and operational by the
> coming friday. I say, why don't they just send me a
> set of their backup tapes and I'll run their
> application on the production HP e3000 here at the
> datacenter. The boss tells me, they DON'T
> HAVE ANY BACKUP TAPES. Fine, then send me the system
> and if it works when it gets here,
> we're good. Otherwise, we're pretty much SOL. After
> about a 16 hour ride in the back of an
> unpadded straight body truck from Maine in the winter
> traveling down I-95, I get the system. With
> about two hours of warm up time in the computer room
> I fire up the box. It's been running
> continuously since early March of this year and
> didn't lose a single bit of information and I haven't
> rebooted it since then. However, before I let any
> users on it, I did do a full and complete backup
> and CSLT.
>
> Cortlandt, your final challenge is to reproduce the
> above scenario with any other maker's computer
> system of similar functionality and size and have it
> survive the ordeal in the same way. You may
> find one, but my guess is it will be some kind of
> mil-spec special order device.
>
> So, as I said before, the HP e3000 is THE MOST ROBUST OLTP
> SERVER AVAILABLE.
>
> First off, I don't use dynamic recovery. I'm sorry if it
> sounded like I did. Quite frankly, Image/SQL
> is so robust that I've never felt the need to use it. And
> I've been using it for well over 15 years!
>
> Now, regarding the dynamic rollback feature of Image/SQL
> versus Oracle's SQL COMMIT. You can kill Oracle very
> easily. Just consider doing a million row update of a
> table in a tablespace that has too few redo logs
> configured for it. It will gag on the update for a
> similar reason that dynamic rollback does. You have
> exceeded the design constraint for that particular DBMS.
> But, with Image/SQL you do a reboot and after a few
> minutes, the XM has posted all valid transactions BEFORE
> the offending transaction and you're back in business.
> Then, you can fix the offending code that you wrote to
> break up the behemoth transaction into smaller pieces.
> With Oracle you'll probably have to reboot your box and
> then recover your tablespace using one of a myriad of
> methods that you either have enabled or you have to do
> manually. My experience is that Oracle takes far longer
> to do its thing than Image/SQL. Once recovered, you too
> must fix the offending code until you can proceed.
>
> So, for my money, I'll stick with what works the best.
> Hopefully now, you and your professor will be able to
> sleep better at night knowing that I didn't falsify my
> claims of robustness!!
>
>
>
>
>
> John Hornberger
> Sr. Systems Programmer
> SPX Corporation
>
>
>
>
> Cortlandt
> Wilson To:
[log in to unmask]
> <cortlandt@COR cc:
> TSOFT.COM> Subject: Re:
[HP3000-L] HP's
> Sent by: Multi-OS strategy includes
MPE
> HP-3000 (take 2)
> Systems
> Discussion
> <HP3000-L@RAVE
> N.UTC.EDU>
>
>
> 08/21/2000
> 06:55 PM
> Please respond
> to Cortlandt
> Wilson
>
>
>
>
>
> <While I see your point, I don't think you get mine. After all,
> > we're NOT preparing a legal brief here. We're trying to
> > spur interest in a platform that deserves a second look. . . .
> > Besides, with all the totally overinflated B.S. in the world
> > surrounding computers, I think this line is but a smidgen, if at
> all.
>
> With all the "totally overinflated B.S. in the world" lets make the
HP
> e3000 a haven of common sense. I mean that is part of our message
> isn't it? It doesn't make sense to me to position the platform as
> the real meaning of quality using low quality claims. I don't
want
> to position the HP e3000 as just more of the same. IMO a "Unix
> quality" ad doesn't make sense for MPE/iX.
>
> The idea itself that the HP e3000 is relatively robust is not a
> "smidgen" - it's the main point. It doesn't make sense to me to
> play games with the key selling point.
>
> With all the hype in this industry a no-B.S. ad might stand out.
>
> I am also remembering that our target marketing includes HP
marketing
> and HP investors. Our claims should be able to hold up to their
> scrutiny.
>
> - Cortlandt
>
> P.S. I am impressed (seriously) that you have used the dynamic
> rollback feature. It doesn't seem that there are alot of us out
> there that have. I don't personally know of any application still
in
> production that uses it.
>
> <[log in to unmask]> wrote in message
> news:39a18172$1_2@skycache-news.fidnet.com...
> > Cortlandt responded to the claim in my ad copy:
> >
> > With over 25 years of innovations your CSY team has improved
> > this platform to the point where it is the most robust OLTP
> > server available.
> >
> > > John,
> >
> > > That is a bold claim. Can you quickly justify it? The "jury"
> > > will be the readers of the ad.
> >
> > > The IT world is full of hype. If anyone else were to claim
> > > that their operating system is THE best in a demanding category
> > > like robustness I would be very suspicious. Lets be sure that
> > > our claims are as reliable as MPE/iX.
> >
> > > I would point out that the dynamic rollback feature of Image --
> > > Image's functional equivalent of the SQL "COMMIT" statement --
> > > sometimes fails.
> >
> >
> > Cortlandt,
> >
> > While I see your point, I don't think you get mine. After all,
> we're NOT
> > preparing a legal brief here. We're trying to spur interest in a
> platform
> > that deserves a second look. So, I graciously invite "any other
> computer
> > maker" to refute my claim with hard facts. I don't think you'll
> find too
> > many takers. Besides, with all the totally overinflated B.S. in
the
> world
> > surrounding computers, I think this line is but a smidgen, if at
> all. I
> > mean, after all, when it comes to computers, define the word
> "robust".
> >
> > And as far as SQL COMMIT is concerned, I have seen that fail on
more
> than
> > one occasion. But, you've never seen or heard Oracle admit to
that
> > happening. That's a bug, not a feature!
> >
> > John Hornberger
> > Sr. Systems Programmer
> > SPX Corporation
> >
>
>
>
|
