QTP migration questions

[Pat Shugart]

Jon,

That is one thing I wouldn't have thought to be true (better base
performance), but from the replies I've gotten and from other companies
that have migrated, it seems to be the case. Let's hope that holds true
for us!

I'd like to thank everyone who replied. I've been given a lot of good
information to discuss with our programmers and DBAs.

/pat

>>> <Jonbickel@aol.com> 1/12/2005 11:33:10 AM >>>
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.
>
= = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.