Hi Y'all!

We had a long transaction rollback on a test system. Here's the report in the message.log:

01/21/2026 15:42:10   Aborting Long Transaction: tx: 0x1d298fba8 ID: 847 username: reubens uid: 5168
01/21/2026 15:42:10   Rollback For Long Transaction 847 Started.
...
01/21/2026 15:42:11   Rollback For Long Transaction 847 Completed. Rollback Duration: 1 Second
01/21/2026 15:42:11   Long Transaction 847 Aborted. (LSN 3052874:0x7ef36ec)

Had I been monitoring it at the time I might have run onstat -x to grep for the transaction ID.  But I would have gotten nothing because that kind of number just ain't on onstat -x.. Here's a sample of onstat -x, filtered for a actual starting address:

onstat -x|awk '$5 != "-" {print}'

IBM Informix Dynamic Server Version 14.10.FC8D4 -- On-Line -- Up 35 days 23:30:08 -- 14843904 Kbytes
2026-01-21 16:07:00

Transactions
                                                                                           est.
address          flags userthread       locks  begin_logpos      current logpos    isol    rb_time  retrys coord
1231641a8        A-B-- 1be3c7d28        24     3052846:0x4ff4018 3052846:0x9820018 DIRTY   00:00:00 0
125f9a428        A-B-- 1abb4f728        24     3052855:0x29c91b4 3052855:0x652a018 DIRTY   00:00:-2 0
12627f4a8        A-B-- 123127528        24     3052922:0x19b01b8 3052924:0x99a6174 DIRTY   00:00:00 0
126526c28        A-B-- 1dd5e4b28        4      3052905:0x9b59358 3052905:0x9b59390 DIRTY   00:00:00 0
148495c28        A-B-- 1be3d2828        36     3052922:0xae1e018 3052923:0x701b354 DIRTY   00:00:00 0
1d2994c28        A-B-- 1dd5e8a28        1      3052925:0x30dc018 3052925:0x30dc31c COMMIT  00:00:00 0

OK, so what is the transaction id number in that output? Isn't it the address?  Nothing up there that could have been 847.  If I were monitoring with sysmaster:systrans I would see a simple integer column: tx_id.  But that does not show in the onstat command. So LTX message is kinda useless for quick diagnosis, before it's gone from memory.

I am probably reinventing a wheel, trying to compose an SQL that connects systrans <=> syssessions to give the DBA something to chase (besides his own tail.)  There is surely a documented intermediary table/view that has one column to join systrans and another to join with syssessions.  HMMmmm... This might just be the bottom line of my question:  How to connect systrans with syssessions.

Ideas, please?  Thanks!

------------------------------
+-----------------------------------------------------------+
| I am pleased to report that I had no problems today. |
| I had only issues, opportunities, challenges and valuable |
| learning experiences. |
+------------------------------------------ Jacob S --------+
------------------------------

Original Message:
Sent: 1/21/2026 6:03:00 PM
From: Paul Watson
Subject: RE: Long transaction message discusses a strange number

I think ID: 847 is the onlog ID

Why not hang on the engine on a LTX and you spend an age looking at what is happening

On 1/21/2026 3:52 PM, Jacob Salomon via IBM TechXchange Community wrote:

0100019be28bd085-24a4ba30-39cf-4e8a-9819-e2a5221b6ae6-000000@email.amazonses.com">

Hi Y'all! We had a long transaction rollback on a test system. Here's the report in the message.log: 01/21/2026 15:42:10 Aborting Long...

Original Message:
Sent: 1/22/2026 12:30:00 PM
From: Jacob Salomon
Subject: RE: Long transaction message discusses a strange number

Thanks for the notion, Paul.

But there are many users who would object most vociferously (and not soto voce) to one neglectful user (who walked away from an open transaction) blocking the server.

• JS

Hi Jake,

for matching "Aborting Long Transaction: tx: 0x1d298fba8 ..." with onstat -x, simply go by this tx address.

The tx_id's use, for the user, mainly is to identify the transaction in onlog output, in combination with LSN info (log unique ID + log position within that log).

A transaction typically is owned by a thread (txn's owner shown as thread's rstcb), and threads are associated with sessions.
So, in onstat terms, you'd match onstat -x with onstat -u to get to session id, and from there to onstat -g ses <sid>.

As for SMI tables/views: systxptab/systrans, sysrstcb/sysusertab + sysscblst/syssessions.

Andreas

------------------------------
Andreas Legner
Informix Dev
HCL Software
------------------------------

Hi,

I hade the same problem, I simulate a Longtansaction and at the end I create this script to monitor it.
this will find sessions with Longtansaction, and write all ses information once to log file .

good luck 

//Layth

#!/bin/bash

LOGG="/var/informix/log/db_longtx.log"
CDATE=$(date "+%Y-%m-%d %H:%M:%S")
echo "$CDATE:start" >>$LOGG

if [[ ! -f $LOGG ]]
        then
        touch $LOGG
        chmod 666 $LOGG
fi

SID=`onstat -u |grep "RPX"|grep -v Version |awk '{print $3}'`
if [[ "$SID" != "" ]]
        then
        echo "Longtansaction accord" >>$LOGG

        for ses in $SID
                do
                check_ses_exist=`grep $ses  $LOGG`

                if [[ "$check_ses_exist" = "" ]]
                        then
                        echo "$ses" >>$LOGG
                        echo "----------------------" >>$LOGG
                        onstat -g ses $ses >>$LOGG
                fi
        done
else
echo "$CDATE:No longtransaction" >>$LOGG
fi
CDATE=$(date "+%Y-%m-%d %H:%M:%S")
echo "$CDATE:End" >>$LOGG
--------------------

you can even use this query to find the session and the pid

SELECT
   A.SID,
   A.USERNAME,
   a.progname,
   LONGTX 
FROM
   SYSRSTCB B,
   SYSTXPTAB C,
   SYSSCBLST A 
WHERE
   C.OWNER = B.ADDRESS 
   AND A.ADDRESS = B.SCB 
   AND longtx != 0 
ORDER BY
   LONGTX DESC

------------------------------
Layth Yousif
------------------------------