Probs in 8.40D - dmapifil and dmaudfil files might help
Lemin, Graeme
Graeme.Lemin@team.telstra.com
Tue, 19 Apr 2005 10:22:44 +1000
Hi Gavin
Details as follows:
The eta for delivering a new PowerHouse 8.40 which will include the fix for problems 474155 : "Unable to find newly created DFK in qkgomaint" and 474636 "8.40D forces read only transaction to read write" is Tuesday, April 19th.
I hope this helps!
regards
Graeme
> -----Original Message-----
> From: Lloyd, Gavin [SMTP:gavin.lloyd@fmglobal.com]
> Sent: Monday, 18 April 2005 9:29 pm
> To: Lemin, Graeme; Joe Boyle; powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D - dmapifil and dmaudfil files might help
>
> Can you let me know what version and any bug/fix numbers that are
> relevant because this could mean that we can look at upgrading again.
>
> Regards,
> Gavin.
>
>
> -----Original Message-----
> From: powerh-l-admin@lists.sowder.com
> [mailto:powerh-l-admin@lists.sowder.com] On Behalf Of Lemin, Graeme
> Sent: 18 April 2005 00:32
> To: Joe Boyle; powerh-l@lists.sowder.com
> Subject: RE: Probs in 8.40D - dmapifil and dmaudfil files might help
>
>
> 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.
> >
>
>
>
>