Tom Emerson ([log in to unmask]) wrote:
 
: Q1: how do I avoid hitting the "MAX XACT"?  (related: how can I make
: the MAX XACT something larger than 1, and be sure it stays that way?)
 
Use the SQLUTIL command called ALTDBE to set the Maximum # of Transactions
to a larger number.  The largest value possible is 240.  In G.0 and previous
versions, the default was 2, so it was pretty easy to hit this problem.
In G.1, the new default is 50.  G.1 is available on MPE/iX 5.0 Express 3,
and also in 5.5.
 
<snip>
: When I get back to a working session via WRQ, and
: attempt to kill the session from ISQL using the "TERMINATE USER"
: command, I end up locking up THAT session on the connect attempt.
: SQLMON tells me that the DBEnvironment's maximum transaction limit has
: been reached, so it won't attempt to map a few system related tables.
 
These are side effects of hitting the transaction limit.  A transaction is
a "unit of work" - if you can't get a transaction, nothing much can happen.
 
: Meanwhile, the /load screen shows all access levels to be at 0%,
: meaning nothing is happening, but the /lock screen doesn't detect any
: deadlocks.
 
You are not waiting to obtain a lock, you are waiting to obtain a transaction
"slot".  Use the /overview or the /load screen to detect this problem.  When
ACTIVE XACT equals MAX XACT, you've hit the limit.  The /load screen also
shows THROTTLE WT, which is the number of sessions who are waiting to obtain
a transaction.
 
BTW, the /lock screen doesn't show deadlocks, per se, it simply shows locks.
 
: Q2: What is DBCORE INTERNAL ERROR 147 (DB-somesuch-ERR 13262)?
: Usually, I get a message box with the message to write down "both
: numbers above" repeated three times in the same message box.
 
DBERR 13262 is a generic message that is used whenever an unexpected internal
error is encountered.  The actual error is also printed in the message (in
this case, it was 147)  The number 147 is only meaningful to engineers who
debug the problem.  In your case, I think it may be related to the error
handling (or perhaps lack of) in the PC software when transactions are not
started successfully.  Bottom line - I think the problem may go away when you
bump the transaction limit to a higher number.
 
Hope this helps,
Leslie-Anne