QTP / TurboImage / MPE/iX

[Tom Renz]

Hans,

A few things you may also might want to address when enabling Autodefer.
Without changing any modes you can enable the database for "Autodefer" via
DBUTIL and then disabling it after your load is complete.  

Make sure you have a backup of the database or an equivalent just in case
the system doesn't fail on you during the middle of this load.  If a
failure does happen then you need to get in contact with either Adager or
Bradmark to see if they can assist you.  This is because the database is in
an inconsistent state during Autodefer because disk posting is not done for
each record being added but the disk posting is deferred until the block
becomes full and you have moved on to the next blocks, hence the term
"autodefer".  I've had a CPU failure during an autodefer load job and was
able to recover and start over from the point of the failure but time was
lost to recover.  

The last item is that if the data set that is being loaded has
Omnidex/Superdex/TPI installed on it, make sure you disable TPI and rename
the "base0A" file to keep the records from being indexed during your loads.
 This will slow down your process and you may not see much gain in load
time.  It is quicker to disable the use of TPI, load the records, and
reindex only the set(s) loaded than it is to keep TPI active, especially
when there 1,000s of records being added.  

Happy loading....

Tom Renz
COTC Technologies, Inc.

At 10:29 AM 5/18/99 +0200, Hans-Ole Kaae wrote:
>Hello listers,
>
>We are doing some Y2K-conversions, QTP-extracting the data sets from the
>production base to PH-subfiles and QTP-loading the data from these subfiles
>back in a fresh base, while doing different Y2K-stuff in the latter QTPs.
>
>While the extracts are fairly quick to run, the load-runs - putting the data
>back in this new base are performing extremely slow as we in fact expected -
>so we are considering different approaches to overcome this problem, since
>we simply haven't got enough wall time during the "live" conversion weekend.
>
>If we decide to keep on letting QTP do these jobs, we would like to enable
>the (new) base for Deferred Output, which is simple enough and this is
>expected to give us a 10-20% performance boost.
>
>But how do we force QTP to open the base in mode 3? Just couldn't find
>anything about this in the PH-books, but I vaguely remember being able to do
>so many, many years ago...
>
>If anybody has the answer to this or a good idea, I'll be very happy indeed.
>
>
>With kind regards,
>
>/Hans
>
>====================================================================
>Hans-Ole Kaae                       Vox: (+45) 87 34 55 07
>IT-Consultant                       Fax: (+45) 87 34 55 66
>ScanConsult·IT-Partners ApS         Mob: (+45) 40 42 55 07
>Udviklingsparken Aarhus             E-mail: hok@scanconsult.dk
>Soenderhoej 14
>DK-8260  Viby J.
>Denmark                             Web: http://www.scanconsult.dk
>
>
>= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
>Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
>Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
>powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
>This list is closed, thus to post to the list, you must be a subscriber.
> 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.