Mr. Hornberger,
I believe your last message contains several red herrings.
Regarding transaction logging.
My statement was "MANMAN 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." The transaction logging I was
referring to was TurboImage transaction logging, which like strong
locking and dynamic rollback recovery, are features of the TurboImage
DBMS and the TurboImage intrinsics. TurboImage transaction logging
is enabled by the DBA and occurs at the intrinsic level.
Yes, you are correct about the existence of MANMAN TR log files and
other application level logging. You correctly call it "partial
logging" for it is very partial indeed. The logging of the TR files
is separate from Image logging and is not protect by a dynamic
rollback or any kind of Image rollback recovery.
All that said, your rejoinder has the appearance of a man desperately
grasping at straws. First, unlike TurboImage's transaction logging,
MANMAN offers little in the way of rollback or recovery from it's
application level logs. Second, you said nothing about the data
integrity problems I wrote about. Finally, the most relevant point
is the impact of logging and recovery/robustness features on
performance and speed. I quote myself again:
> 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 the robustness features have a noticeable
> 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.
I agree with your statement that "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." I have spoken a MANMAN R&D
manager about why the code doesn't use these robustness features and
one of the reasons given was decreased performance. The point is,
that in terms of robustness, it isn't fair or reasonable to compare
MANMAN performance against a application that uses transaction
logging, strong locking, and dynamic rollback recovery. That is
comparing apples and oranges. To the extent that MANMAN is typical
of other HP 3000 applications (and I believe that it is) then
performance comparisons between HP e3000 applications and applications
on other platforms are highly suspect.
Unfortunately there are no published performance ratings for Oracle on
the HP 3000. The best we have is a out of date and unsubstantiated
report of superior performance. Since it looks like Oracle 7 will be
the first and last port to the HP 3000 and Oracle is currently working
on Oracle 9, performance of Oracle under MPE/iX is becoming, or
already is, a moot point.
Hornberger:
> 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!
That is an interesting theory, however, a significant percentage of
the data integrity corruption that I have seen with MANMAN were not
attributable to operating systems failures. Programs being aborted
during logical transactions, program bugs that cause an abnormal
termination during a logical transaction, full datasets, full disk
drives, and errors caused by missing or duplicate keys and other
integrity problems that would have been prevented with strong locking
accounted for a significant amount of data corruption. Nearly all of
these problems are preventable using the programming techniques
recommended in the TurboImage/XL Data Management System Reference
Manual (especially under MPE/iX 6.5) but at the cost of performance.
I must admit that I don't know how big the performance hit is. My
one experience with logic coded with textbook strong locking and with
dynamic rollback enabled was that the impact on response time can be
quite noticible. (Users on two different systems commented on it.)
There are reasons, however, that cause me to suspect that the case is
not representative of typical OLTP processing. Does anyone know of a
study or estimate of this?
Final thought.
Most codes of professional conduct call for professionals to render
informed, fair, and unbiased opinions. Sadly, I don't believe this
is true of too many claims of HP 3000 performance. In my (dare I say
professional?) opinion, some of these claims are less accurate than
the statements by HP spokesmen that started this discussion.
Cortlandt Wilson
Cortlandt Software
www.cortsoft.com (MANMAN 3rd party Resources site)
(650) 966-8555
<[log in to unmask]> wrote in message
news:39a4360c$1_2@skycache-news.fidnet.com...
> 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
> > >
> >
> >
> >
>
>
>
|
