Probs in 8.40D - dmapifil and dmaudfil files might help
Joe Boyle
atla38@dsl.pipex.com
Sat, 16 Apr 2005 11:04:05 +0100
and you could always set up logicals for dmapifil and dmaudfil. Inspection
of the files mapped to might also shed some light on the cause of the
problem.
Regards, Joe.
-----Original Message-----
From: powerh-l-admin@lists.sowder.com
[mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Lemin, Graeme
Sent: 05 April 2005 04:25
To: Joe Boyle; Deskin, Bob; powerh-l@lists.sowder.com
Subject: RE: Probs in 8.40D
That was my understanding as well. If you add 'set file xxx open read' then
you are explicitly stating the type of access. And certainly what we're
hoping we can do in 8.40D!
regards
Graeme
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
[SMTP:powerh-l-admin@lists.sowder.com] On Behalf Of Joe Boyle
> Sent: Tuesday, 5 April 2005 12:35 am
> To: 'Deskin, Bob'; powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D
>
> all fair comments of course, but if you are adding 'SET FILE xxx OPEN
READ'
> to the qtp, are you not telling qtp that creating a read only additional
> transaction is desired in this case - and that you don't care about the
> consequences of reference-only data being changed during the run/request.
>
> To have to add 'commit at update' in order to release rows/locks is very
> slow, and affects the consistency of the updateable rows as well as the
> reference-only rows, and that is undesirable.
>
> P.S. as always, I recognize that what anyone wants in a given scenario is
> always highly subjective, but apparently 7.10.Gn did what 8.40.D now does
> not do, so if its good enough for 7.10.Gn, why not 8.40.D also :)
>
> Regards, Joe.
>
>
> -----Original Message-----
> From: Deskin, Bob [mailto:Bob.Deskin@Cognos.COM]
> Sent: 04 April 2005 13:47
> To: Joe Boyle; powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D
>
> Keep in mind that the OPEN READ|etc syntax was in QTP originally for
> non-relational files and was adapted for relational. I forget why we did
> that rather than add a transaction statement. However, just because one
> table is opened for read doesn't mean that the entire transaction, which
> may include other tables, should be read-only. the other option would be
> to create an additional transaction, which may not be desirable.
>
> Bob
>
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Joe Boyle
> Sent: April 4, 2005 8:34 AM
> To: powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D
>
>
> I wonder what 'SET FILE xxx OPEN READ' was designed to do if not create
> a read only transaction for the table; and presumably allow other
> processes concurrent read/write access as with reference files in
> screens.
>
> I suppose it could be to block other writers while qtp is accessing rows
> from the table; but I thought that was what the consistency Tx did
> anyway, and so I would expect the 'set file ... read' override to allow
> others read/write access.
>
> Regards, Joe.
>
>
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Lloyd, Gavin
> Sent: 04 April 2005 10:26
> To: Lemin, Graeme; powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D
>
> We are running OpenVMS V7.1-2, Oracle Rdb V7.0-65, Powerhouse 7.10.G4.
>
> We tested 8.30D and experienced the following problems:
>
> Case No: 3122113
> Date Logged: 24-Apr-2003
> Bug No.: 406680
> Fixed: Yes
> Fixed Version: 8.30D3
> Issue: Problem locating database when using searchlist logicals
>
> Case No: 3123401
> Date Logged: 02-May-2003
> Bug No.: 404930
> Fixed: No
> Issue: 'SET FILE xxx OPEN READ' does not create a read only transaction
>
> Case No: 3124064
> Date Logged: 07-May-2003
> Fixed: Yes
> Issue: Retrieval on SMALLINT columns combined with CHARACTER columns
> does not work
> Solution: In the PHD File screen change the type for the databases from
> RDB/VMS to RDB
>
> Case No: 3126513
> Date Logged: 22-May-2003
> Bug No.: 406779
> Fixed: Yes
> Fixed Version: 8.30D3
> Issue: '%RDB-E-UNRES_REL' error
>
> Case No: 1111339
> Date Logged: 30-May-2003
> Bug No.: 407579
> Fixed: Yes
> Issue: 'COMMIT AT RUN' is commiting transactions at each request
> Solution: In the PHD File screen change the type for the databases from
> RDB/VMS to RDB
>
> As you can see 4 of the 5 were resolved (the PHD change needs a full>
> recompile to take effect), but Case 3123401 was deemed a functionality
> change and not 'changed' so you will have to discuss with Cognos.
>
> Regards,
> Gavin.
>
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Lemin, Graeme
> Sent: 01 April 2005 07:17
> To: powerh-l@lists.sowder.com
> Subject: Probs in 8.40D
>
>
> Hi Listers
>
> Our upgrade from 7.10.G1 to 8.40D has struck yet another
> problem.
>
> First off, the usual stuff:
>
> We are currently upgrading from:
>
>
> VMS 7.3-1 and OracleRDB 7.1-03
>
> to
>
> VMS 7.3-2 and OracleRDB 7.1-04
>
> and from Powerhouse from 7.10.G1 to 8.40D.
>
>
> We have experienced severe problems where Powerhouse is locking out
> other processes. Looking at the log file from two requests within a
> single QTP program (with trace flags enabled) we find:
>
> ~T Transaction Parameter Block: (len=4)
> 0000 (00000) TPB$K_VERSION = 1
> 0001 (00001) TPB$K_ISOLATION_LEVEL3 (serializable)
> 0002 (00002) TPB$K_READ (read only)
> 0003 (00003) TPB$K_WAIT
> ~T Start_transaction (1) on db: 3, db count=1
> Get Retrieval by index of relation RDB$RELATIONS
> Index name RDB$REL_REL_NAME_NDX [1:1] Direct lookup
> Sort
> Cross block of 2 entries
> Cross block entry 1
> Conjunct
> Leaf#01 BgrOnly RDB$RELATION_FIELDS Card=9317
> BgrNdx1 RDB$RFR_REL_NAME_FLD_ID_NDX [1:1] Fan=8
> Cross block entry 2
> Get Retrieval by index of relation RDB$FIELDS
> Index name RDB$FIELDS_NAME_NDX [1:1] Bool Direct lookup
> Run: PH_EXT_0
>
> Request: GET_CURR_WORK_ORDERS
>
> Executing request GET_CURR_WORK_ORDERS ...
>
> ~T Compile transaction (1) on db: 2
> ~T Transaction Parameter Block: (len=120)
> 0000 (00000) TPB$K_VERSION = 1
> 0001 (00001) TPB$K_ISOLATION_LEVEL3 (serializable)
> 0002 (00002) TPB$K_WRITE (read write)
> 0003 (00003) TPB$K_WAIT
> 0004 (00004) TPB$K_LOCK_READ (reserving) "WIZ_SALES_AGENTS" TPB$K_SHARED
> 0017 (00023) TPB$K_LOCK_READ (reserving) "CTH_HP_DESCRIPTION"
> TPB$K_SHARED 002C (00044) TPB$K_LOCK_READ (reserving)
> "WIZ_WO_LINE_HISTORY" TPB$K_SHARED 0042 (00066) TPB$K_LOCK_READ
> (reserving) "CTH_WO_HISTORY" TPB$K_SHARED 0053 (00083) TPB$K_LOCK_READ
> (reserving) "WIZ_WO_LINE_ITEMS" TPB$K_SHARED 0067 (00103)
> TPB$K_LOCK_READ (reserving) "CTH_WORK_ORDER" TPB$K_SHARED ~T
> Start_transaction (1) on db: 2, db count=1
>
> As mentioned, these passes are within the same QTP program. The files
> are opened as "OPEN 1 READ SHARE".
>
> If we run the same code, in the same environment but using 7.10.G1, then
> the TPB$K_WRITE parameter is set to READ ONLY in both cases. Our DBAs
> have confirmed that the "read write" is what is causing other
> transactions to be locked out.
>
> This has become a "show stopper" for us, to the point where our customer
> is going to decide on Monday whether it's worth going ahead with the
> upgrade or not.
>
> Has anyone seen anything like this before, or have any suggestions?
>
> Thanks again.
>
> regards
>
> Graeme Lemin
> Telstra Multimedia
> Melbourne, Australia
> +61 3 8695 7040
> graeme.lemin@team.telstra.com
>
>
>
>
>
>
> --
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> 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. >
>
> This message may contain privileged and/or confidential
information.
> If you have received this e-mail in error or are not the intended
recipient,
> you may not use, copy, disseminate or distribute it; do not open any
> attachments, delete it immediately from your system and notify the sender
> promptly by e-mail that you have done so. Thank you.
>
>
> --
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> 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.