Jim,

        It's been many years ago, but I ran into something similar to this.  I actually had two problems, the first was that I needed to do the DBX (EBG/END) transactions using mode3 on the calls...this mode better handles multi DB transactions within the logical transaction set (this would be the first thing I'd look at to see if mode3 is being used).  The second error was with NETBASE causing a deadlock in the shadowed DB when nested DBX logical transactions occurred in a program...unfortunately, I don't recall the specifics of the NETBASE problem (or the correction), but it was at least 6/7 years ago, and I'd bet that NETBASE corrected that error.

        I wish I could recall things better, but this may at least give you somewhere to look.


Happy Monday,


Ray Shahan

> -----Original Message-----
> From: HP-3000 Systems Discussion [SMTP:[log in to unmask]] On Behalf Of Jim Phillips
> Sent: Sunday, August 22, 2004 2:01 PM
> To:   [log in to unmask]
> Subject:           [HP3000-L] DBXBEGIN/END, Locking, and Committment
> 
> Transaction committment, that is, not my committment
> to a mental institution, although it's starting to
> look like a viable alternative to all these political
> threads....
> 
> Anyway, I have a major application that the shop floor
> production personnel use to record production.  It
> touches just about every meaningful data set we have,
> so we designed it using the following logic:
> 
> 1. DBXBEGIN
> 2. DBLOCK an entry in Set X
> 3. DBUPDATE entry in Set X
> 4. Repeat steps 2 and 3 for a number of sets
> 5. DBLOCK an entry in Set Y
> 6. DBPUT entry in Set Y
> 7. Repeat steps 5 and 6 for a number of sets
> 8. DBXEND (or DBXUNDO)
> 9. DBUNLOCK
> 
> In this way, it was hoped that if something untoward
> happended, the logical transaction would be backed out
> via XM, plus we can DBXUNDO in the application if need
> be.
> 
> The problem is that on occasion the logical
> transaction fails to commit; that is, the locks held
> by process A are never released, and since process A
> has some common usage sets locked, it impedes process
> B.  This cascades until everyone is locked up, and the
> only thing I can do at that point is to abort the
> offending process(es).  In looking at the locks held
> using DBUTIL, it does not appear to be a deadly
> embrace.
> 
> So, my questions are:
> 
> 1)  Does the logic above appear to be correct when
> utilizing DBXBEGIN/END?  This appears to be the only
> way you can get it to work because I've tried DBUNLOCK
> inside of the DBXBEGIN and it fails.
> 
> 2)  Are there any known problems with DBXBEGIN/END?
> We are on 7.5 PP1 and the TurboIMAGE overall VUF is
> C.10.05.
> 
> 3)  Any ideas on how to debug this problem?
> 
> 
> TIA,
> 
> Jim Phillips
> 
> 
> 
> 
> __________________________________
> Do you Yahoo!?
> Yahoo! Mail - 50x more storage than other providers!
> http://promotions.yahoo.com/new_mail
> 
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
> 
> ========================================================================
> This e-mail message has been scanned for Viruses and Content and cleared 
> by School Specialty's email filtering solution.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *