Documentation for error codes from tpcall()

Question

Dear all,
while investigating a particular error-handling scenario I realized that the documentation for tpcall() was changed between Tuxedo 6.5 and 7.1.
In the 6.5 docs it's stated that after a TPESVCFAIL error you can do tpcall(..., TPNOTRAN) as long as you haven't run out of TRANTIME.
In the 7.1 (and onwards) docs it's stated that after a TPESVCFAIL error you can only do tpacall(..., (TPNOBLOCK|TPNOREPLY|TPNOTRAN))
In the 6.5 docs this is only stated after TPETIME (which makes some kind of sense - you're already late so don't do a lot of more time-consuming stuff).
On the other handl, in a section in the Tuxedo 10.0 docs about error handling (http://edocs.bea.com/tuxedo/tux100/pgc/pgerr.html#wp1155712) you're again told that it's OK to use tpcall() (and recommended to use TPNOTRAN if doing so)
Is this related to multi-threading, or why was the documentation changed?
Testing shows that you can actually do tpcall(..., TPNOTRAN) after a TPESVCFAIL using Tuxedo 8.1. (after a TPETIME it's another story, but I'm OK with that.) Am I the only one being confused by this?
Best regards,
/Per

Answer 1

I just checked the XATMI spec (dated November, 1995....) which states the following regarding tpcall() failures:
[TPESVCFAIL]
The service routine sending the caller’s reply called tpreturn( ) with TPFAIL. This is an
application-level failure. The contents of the service’s reply, if one was sent, are available in
the buffer pointed to by *odata. If the service request was made on behalf of the caller’s
current transaction, the transaction is marked rollback-only. Note that so long as the
transaction has not timed out, further communication may be attempted before rolling back
the transaction. Such attempts may be processed normally or may fail (producing an error
return or event). Such attempts should be made with TPNOTRAN set if they are to have
any lasting effect. Any work performed on behalf of the caller’s transaction is rolled back
upon transaction completion.
This is consistent with the 6.5 documentation (and 8.1 behaviour). Has the XATMI spec been updated, or what was the rationale for changing the behavior?
Best regards,
/Per