Probs in 8.40D

Mon, 4 Apr 2005 13:33:55 +0100

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 &lt;password&gt;" 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.