Probs in 8.40D - dmapifil and dmaudfil files might help
Lemin, Graeme
Graeme.Lemin@team.telstra.com
Mon, 18 Apr 2005 09:31:58 +1000
We've received advice from Cognos that this 'feature' has been fixed!!
Yay!!
> -----Original Message-----
> From: Joe Boyle [SMTP:atla38@dsl.pipex.com]
> Sent: Saturday, 16 April 2005 8:04 pm
> To: Lemin, Graeme; powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D - dmapifil and dmaudfil files might help
>
> 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.
>