NAT3009 Transaction aborted (additions2: :1:).
-------------------------------------------------------------------
TEXT:
Transaction aborted (additions2: :1:).
EXPL:
This response is caused by one of the following:
- The last user transaction has been backed out by Adabas (ET
logic users only) or an exclusive control user (non-ET user)
or an access-only user exceeded the non-activity time limit;
- The nucleus was abnormally terminated and the user issued a
command;
- The protection log area was too small and an internal BT was
executed.
The ADDITIONS 2 field in the CB contains additional information:
Transaction timeout : 0 - TT Security : 5 - SE
Non-activity timeout: 1 - TN Hold queue deadlock : 6 - DL
STOP user : 2 - ST Read consistency : 7 - RC
LP overflow : 3 - LP OP during transaction : 8 - OP
AUTO-RESTART : 4 - AR Open required for user: 9 - OR
ACTN:
Check the appropriate reason.
My question is: How can I get the content of the “additions2-field” inside an ON ERROR statement? I tried ‘USR0610N’ but this didn’t work.
USR0610N always fills the field DB_ADD1F2B with two spaces. This field should contain the “first 2 bytes off additions1 field”.
By the way: I need Additions2… :oops:
I guess USR2030N is the better idea. TankXXL. I did a test by stopping a user with "adaopr db=123 stop=123’ during a read-update-loop. That works, because the additions2 is “2” (=STOP user) then.
But one question remains: Could it be, that the “last error” is the last error of the database and not the last error of the natural session? What, if many many users or batches are working on the database at the same time? So it would be better, if there would be a NATURAL-Field like *ADD2 or :1: which is filled automatically during ON ERROR processing…
Nope, you are “isolated” from a DB point of view, if you terminate your UQE within ADABAS, this is what’s reported to your NATURAL session, nothing else.
I was just asking, because USR0610T says something about “last DB call error”. That was a bit confusing for me, because in my case, the last DB call could be from another user …