powerh-l Digest, Vol 43, Issue 22

[Alan and Vicki]

Last I knew, QTP uses HP Image intrinsics and does not bypass them.  If you 
delete entries from a detail dataset, Image will automatic delete the 
associated entries in the related automatic master, but not the manual 
master.  If you try to delete from a manual master and there are associated 
detailed records with the key, it will give you an error.  If you're not 
trying to delete records in this QTP run, then the problem may be with the 
database itself, as you seem to already suspect.

My best advice would be to use HP utilities (I believe DBunload/DBload - 
can't remember for sure) to clean out your database and start from 
scratch -- sounds like it could be corrupted -- perhaps a bad case of 
migrating secondaries, or some sort of broken links, etc.  In any event, I 
would try to get that worked out first and unloading/reloading your database 
will give you a nice clean start.  If it is one QTP run only that is causing 
the issue, then perhaps there is something wonky about it, but without 
seeing the code, it is difficult to assess.  Another thing to keep in 
mind -- at least, from the good ol' days -- it is always recommended to use 
a prime number when sizing datasets -- in fact, I think the HP Image manuals 
used to have a list of prime numbers in the back of the book for just that 
purpose -- it will help eliminate some issues with having key values resolve 
to the same address which can ultimately cause corruption in the database.

DBGeneral is a good product, but like most 'cheater' utilities, it does not 
do the same thing as the Image utilities when it comes to straightening out 
a database -- it may be painful, but if you can swing it, I would try the 
clean slate approach first -- make sure you have a good backup of the 
database first, of course.  When you see these kinds of problem recurring, 
it is often indicative of a database that has integrity issues between the 
detail and master datasets.

Good luck!

Vicki


----- Original Message ----- 
From: <powerh-l-request at lists.sowder.com>
To: <powerh-l at lists.sowder.com>
Sent: Monday, December 29, 2008 2:00 PM
Subject: powerh-l Digest, Vol 43, Issue 22


> Send powerh-l mailing list submissions to
> powerh-l at lists.sowder.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sowder.com/mailman/listinfo/powerh-l
> or, via email, send a message with subject or body 'help' to
> powerh-l-request at lists.sowder.com
>
> You can reach the person managing the list at
> powerh-l-owner at lists.sowder.com
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of powerh-l digest..."
>
>
> Today's Topics:
>
>   1. RE:TurboIMAGE database being corrupted by QTP (Walter J. Murray)
>   2. RE:TurboIMAGE database being corrupted by QTP (Ken Langendock)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 28 Dec 2008 21:42:53 -0800
> From: "Walter J. Murray" <wmurray at surewest.net>
> Subject: RE: TurboIMAGE database being corrupted by QTP
> To: "'Peter Bateman'" <peterbateman808 at hotmail.com>, "'PowerHouse
> List'" <powerh-l at lists.sowder.com>
> Message-ID: <002101c96978$4b4784a0$a0f23e45 at DJFJQK21>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Peter and the group,
>
> I have eliminated QTP from the picture.  I can duplicate the problem
> with a COBOL program calling DBPUT directly.
>
> The only way I know to eliminate Bradmark (DBGENERAL) from the picture
> is to rebuild the database using only HP utilities, which I am in the
> process of doing.
>
> I'll post what I learn.
>
> Thanks.
>
> Walter
>
> Walter J. Murray
>
> -----Original Message-----
> From: powerh-l-bounces+wmurray=surewest.net at lists.sowder.com
> [mailto:powerh-l-bounces+wmurray=surewest.net at lists.sowder.com] On
> Behalf Of Peter Bateman
> Sent: Friday, December 26, 2008 10:52 AM
> To: walter murray; PowerHouse List
> Subject: RE: TurboIMAGE database being corrupted by QTP
>
> Hi Walter:
> ?
> ??? You say:- "I can duplicate the problem consistently on a test
> machine."
> ????This is good.
> ??? I would try it without Bradmark in the picture. Just to eliminate
> one vendor.
> ??? If it reproduces without Bradmark great. If not I would call them to
> see
> ??? if they can debug this problem.
> ?
> Regards,
> Peter Bateman
> ?
> ???
> ???
>
>
>> From: wmurray at surewest.ne
>> To: powerh-l at lists.sowder.com
>> Subject: TurboIMAGE database being corrupted by QTP
>> Date: Wed, 24 Dec 2008 20:02:53 -0800
>>
>> [Also posted to HP3000-L]
>>
>> TurboIMAGE database being corrupted by QTP
>>
>> Please help me get to the root of this problem. It looks like either a
>> bug in TurboIMAGE (I hope not!) or a bug in PowerHouse 4GL (hard to
>> imagine).
>>
>> Environment: MPE/iX 7.5 PP3, PowerHouse 8.39.C1.
>>
>> I have this production database that occasionally gets corrupted
> during
>> a QTP run. I can duplicate the problem consistently on a test machine.
>> I don't just mean corrupted with bad data--I mean structural errors in
>> the database. The errors always seem to be associated with a
> particular
>> detail data set. DBGENERAL typically reports the errors as (1) FREE
>> SPACE COUNT INCONSISTENT, (2) DELETE CHAIN MISSING ENTRIES, and (3)
>> DELETE CHAIN BROKEN. Sometimes there are also structural errors
> related
>> to the paths between this detail data set and the two related
> automatic
>> masters. I can repair the damage with DBGENERAL, but the database gets
>> corrupted again in a few days.
>>
>> QTP reports the problem with these error messages:
>> "Data access error."
>> "Action Taken: Run terminated."
>> "MPE FILE ERROR 0 RETURNED BY FREADDIR ON ROOT FILE"
>>
>> After QTP terminates the run, I check the database and find it
>> corrupted.
>>
>> I am thinking that TurboIMAGE usually does an excellent job of
>> protecting itself against structural errors. Without using PM, it
>> shouldn't be possible for an application to damage a database in this
>> way. I wonder whether QTP always uses the IMAGE intrinsics, or whether
>> it might sometimes sidestep IMAGE and modify internal database
>> structures directly. Does anybody know?
>>
>> The detail data set in question has about 15,000,000 entries. It is
>> enabled for dynamic expansion, but the current capacity is still equal
>> to the initial capacity, so no expansion has occurred yet. None of the
>> master data sets is enabled for dynamic expansion. The data set is
>> related to two automatic masters, and both of those paths are sorted.
>>
>> I've placed a support call with COGNOS, but they haven't come up with
>> anything yet. I also plan to place calls to HP and Bradmark. Can
>> anybody help in the mean time? Thanks.
>>
>> Walter
>>
>> Walter J. Murray
>>
>>
>>
>> --