QTP migration questions
Jonbickel@aol.com
Jonbickel@aol.com
Wed, 12 Jan 2005 11:33:10 -0500
Ken raises a very good practical point regarding the performance boost implicit in the platform/db change itself.
In my one HP3k to HP9k upgrade/migration, absolutely everything ran faster on the UNIX side. Thus performance was never an issue from the user's perspective and I was able gradually incorporate optimizing changes such as cursors and views while making typical day-to-day functional enhancements after the migration was complete.
Granted, the performance boost was partially due to hardware upgrades in the migration, but this implicit change may be a factor in Pat's case as well. As may the distinction between 'optimal' and required performance.
jb
In a message dated 1/12/2005 10:29:59 AM Eastern Standard Time, Ken Langendock <ken.langendock@rogers.com> writes:
>Ok from what you have told me here, my suggestion
>would be to keep QTP running. Learn basic SQL and
>replace all your access statments with cursor. First
>off your team will be learning SQL and still using
>their experience in powerhouse. They should also be
>learning VI to allow them to float from one Unix line
>to another....believe me, Qedit (or whatever you use
>is obsolete) and you can get VIM for the PC.
>
>Then comes the fun part. If after you have implemented
>cursors and did not get enough of a performance
>improvment from doing this (which I doubt, I used to
>call Turbo Image...Turtle image after moving to a
>unix/oracle env), you can start moving some of the
>business logic into the database. Ie. Integrity
>triggers (if I add a record here, it needs to update
>that field over there in that file), this should
>remove some code. Next add Views, you should be able
>to remove more code from this and finally stored
>procedures. Here is where you will take the most
>amount of time and remove the most amount of code from
>your QTP processes.
>
>Hope this helps...this is my approach.
>Ken
>
>
>
>
> --- Pat Shugart <ShugartP@trinity-health.org> wrote:
>> Good points, Ken.
>>
>> We're not replacing Powerhouse. We're keeping QUIZ
>> already and trying
>> to figure out whether or not to add QTP.
>>
>> Our decision to continue to use QTP comes down to
>> two things: Timeline
>> and performance.
>>
>> If we convert QTP to <whatever>, we do not have the
>> resources to do it
>> in-house and maintain our timeline. So, each QTP
>> process will have to be
>> documented for a re-write for the company doing the
>> re-write. We do not
>> document each individual process in our jobs, only
>> the overall process
>> being performed for the business. So, we'd have to
>> go into each QTP and
>> write down what it does. That alone will impact the
>> project schedule.
>>
>> Ken, when you write that moving more functionality
>> into the database
>> will improve performance, what do you mean by that?
>> Placing business
>> logic into things like stored procedures? I'm not
>> Oracle-savvy, so
>> please excuse my ignorance. I have been promised by
>> the time the project
>> is complete, I'll know more about Oracle than I'll
>> ever care to. :)
>>
>> Thanks,
>> /pat
>>
>> >>> ken.langendock@rogers.com 1/12/2005 8:51:54 AM
>> >>>
>> I guess it comes down to what your timeline is:
>> Are you replacing Powerhouse completely or just
>> thinking about replacing QTP?
>>
>> I work for a company that sells multi-million dollar
>> powerhouse product and have improved QTP using
>> cursors. There are some cases where moving more
>> functionallity into the database improves
>> performance.
>> But this may only become appearent after being in
>> production for a while.
>>
>> If you are just worried about qtp. Convert the app
>> and
>> add cursors to every qtp process. You will see an
>> incredible performance improvement.
>>
>> Ken
>> --- Pat Shugart <ShugartP@trinity-health.org> wrote:
>>
>> > I'm sorry. Forgot to mention we'll be migrating to
>> > an Oracle database
>> > environment located on the HP9000 (HP-UX).
>> >
>> > >>> "Joe Boyle" <atla38@dsl.pipex.com> 1/12/2005
>> > 8:38:09 AM >>>
>> > I can't see what database you are using but memory
>> > tells me that Oracle
>> > was
>> > quite slow on Mpe, so, in my opinion, this will be
>> > faster on the 9000
>> > without any changes.
>> >
>> > As always, choose will be equivalent in
>> performance
>> > to sql declare
>> > cursor
>> > syntax, but qtp 'select if' syntax will always be
>> > slower that anything
>> > that
>> > is processed within the database e.g. 5 minute
>> runs
>> > reduced to 5
>> > seconds
>> > when using cursors.
>> >
>> > Regards, Joe.
>> >
>> > This e-mail and all information contained in it is
>> > confidential and may
>> > be
>> > legally privileged. If you are not the intended
>> > recipient, your access
>> > to
>> > this e-mail is unauthorized. Any use,
>> dissemination,
>> > distribution,
>> > publication or copying by you of this e-mail or
>> any
>> > of the information
>> > contained within it is prohibited and may be
>> > unlawful. Do not open any
>> > attachments, delete it immediately from your
>> system
>> > and notify the
>> > sender
>> > promptly by e-mail that you have done so. The
>> > content of this e-mail
>> > and any
>> > attachments sent with it may have been altered
>> > without the consent or
>> > knowledge of the author.
>> >
>> > -----Original Message-----
>> > From: powerh-l-admin@lists.sowder.com
>> > [mailto:powerh-l-admin@lists.sowder.com] On Behalf
>> > Of Pat Shugart
>> > Sent: 12 January 2005 13:03
>> > To: powerh-l@lists.sowder.com
>> > Subject: QTP migration questions
>> >
>> > Hello all,
>> >
>> > We're an Amisys shop in the final planning stages
>> of
>> > our migration from
>> > the
>> > HP3000 to Amisys Advance on an HP9000. One of the
>> > decisions we need to
>> > make
>> > is what to do about QTP.
>> >
>> > Choice #1: Convert QTP code to SQL (we use PL/SQL
>> > for other apps). As
>> > I
>> > understand it, performance is the greatest
>> advantage
>> > of doing this.
>> > The
>> > "disadvantage" is that we have to rewrite all of
>> our
>> > QTP code (and
>> > document
>> > it!) and it would take quite some time, as we have
>> > approximately 85
>> > QTP
>> > processes of varying degrees of complexity.
>> >
>> > Choice #2: Continue to use QTP on the 9000. The
>> > advantage is that
>> > relatively
>> > few changes will need to be made to our code and
>> the
>> > migration/test
>> > period
>> > can be shortened. The great unknown is
>> performance.
>> > Is it (nearly) as
>> > fast
>> > as SQL code? For you HP3000 users, I draw a
>> > comparison to what happened
>> > to
>> > Suprtool. I understand it is not nearly the same
>> > tool it was on the
>> > HP3000.
>> > I haven't been able to find any sort of comparison
>> > docs between the MPE
>> > and
>> > HPUX versions of QTP.
>> >
>> > I would appreciate both real-world and theoretical
>> > thoughts regarding
>> > our
>> > choices. Please don't call or email me about
>> > migration "solutions".
>> > Most of
>> > those decisions have already been made. Although
>> > alternatives to the
>> > choices
>> > above are welcome...
>> >
>> > This may have been a duplicate post * my first
>> > attempt was rejected
>> > when I
>> > sent it to the previous listserv address. Sorry.
>> >
>> > Thanks in advance,
>> >
>> >
>> > `....`....`....`....`....
>> > Pat Shugart
>> > Trinity Information Services
>> > 34605 Twelve Mile Road
>> > Farmington Hills, MI 48331
>> > 248.489.6123
>> > 248.488.9195 (fax)
>> >
>> >
>> >
>> > = = = = = = = = = = = = = = = = = = = = = = = = =
>> =
>> > = =
>>
>=== message truncated ===
>= = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Mailing list: powerh-l@lists.sowder.com
>Subscribe: "subscribe" in message body to powerh-l-request@lists.sowder.com
>Unsubscribe: "unsubscribe <password>" in message body to powerh-l-request@lists.sowder.com
>http://lists.sowder.com/mailman/listinfo/powerh-l
>This list is closed, thus to post to the list you must be a subscriber.
>