SESDEBUG parameter: Difference between revisions

From m204wiki
Jump to navigation Jump to search
 
(4 intermediate revisions by 4 users not shown)
Line 1: Line 1:
{{Template:SESDEBUG parameter subtitle}}


==Summary==
==Summary==
Line 11: Line 12:
<dd>All
<dd>All
<dt>Introduced
<dt>Introduced
<dd><var class="product">Sirius Mods</var> 8.0
<dd><var class="product">[[Sirius Mods]]</var> 8.0
</dl>
</dl>
==Description==
==Description==
Line 20: Line 21:
<dl>
<dl>
<dt>X'01'
<dt>X'01'
<dd>Issue message MSIR.1050 whenever a session is closed with exclusive record locks in session objects.
<dd>Issue message [[MSIR.1050|MSIR.1050]] whenever a session is closed with exclusive record locks in session objects.
<dt>X'02'
<dt>X'02'
<dd>Issue message MSIR.1051 whenever a session is closed with exclusive record locks in session objects, but undo the request cancellation normally caused by MSIR.1051. This allows a SirFact dump to be collected for the problem without actually causing the request to be canceled.
<dd>Issue message [[MSIR.1051|MSIR.1051]] whenever a session is closed with exclusive record locks in session objects, but undo the request cancellation normally caused by MSIR.1051. This allows a [[SirFact|SirFact dump]] to be collected for the problem without actually causing the request to be canceled.
<dt>X'04'
<dt>X'04'
<dd>Issue message MSIR.1051 whenever a session is closed with exclusive record locks in session objects. This allows a SirFact dump to be collected for the problem and then terminates the request and deletes the session, preventing the record locks from causing any lock conflicts.
<dd>Issue message MSIR.1051 whenever a session is closed with exclusive record locks in session objects. This allows a SirFact dump to be collected for the problem and then terminates the request and deletes the session, preventing the record locks from causing any lock conflicts.
Line 32: Line 33:
<dd>Issue message MSIR.1051 whenever a session is closed with any (share or exclusive) record locks in session objects. This allows a SirFact dump to be collected for the problem and then terminates the request and deletes the session, preventing the record locks from causing any lock conflicts.
<dd>Issue message MSIR.1051 whenever a session is closed with any (share or exclusive) record locks in session objects. This allows a SirFact dump to be collected for the problem and then terminates the request and deletes the session, preventing the record locks from causing any lock conflicts.
</dl>
</dl>
==Notes==
==Notes==


MSIR.1050 indicates the session object name that can be used to get to the object with the record lock and the strength of the lock. If multiple session objects can be used to get to multiple objects with record locks, only one is indicated by the message and the greatest lock strength s indicated.
MSIR.1050 indicates the session object name that can be used to get to the object with the record lock and the strength of the lock. If multiple session objects can be used to get to multiple objects with record locks, only one is indicated by the message and the greatest lock strength is indicated.


Specifying lower bits is redundant. That is, there is no difference between SESDEBUG X'04', and X'05', and X'06', and X'07', the X'04' bit causes request cancellation on a detected exclusive record lock. Similarly, SESDEBUG X'22' and X'20' have identical meaning, they will both issue MSIR.1051 without cancelling the request for any record locks in session objects. SESDEBUG X'14' is different from X'10', however, because X'14' will cause request cancellation for an exclusive lock in a session object and a only a message for a share lock, while X'10' will only result in a message, regardless of the lock strength.
Specifying lower bits is generally redundant. That is, there is no difference between SESDEBUG X'04', and X'05', and X'06', and X'07', the X'04' bit causes request cancellation on a detected exclusive record lock. Similarly, SESDEBUG X'22' and X'20' have identical meaning, they will both issue MSIR.1051 without cancelling the request for any record locks in session objects. SESDEBUG X'14' is different from X'10', however, because X'14' will cause request cancellation for an exclusive lock in a session object and a only a message for a share lock, while X'10' will only result in a message, regardless of the lock strength.




[[Category:User parameters]]
[[Category:User parameters]]
[[Category:Parameters]]
[[Category:Parameters]]

Latest revision as of 14:05, 30 May 2017

Session debugging flags

Summary

Default value
0
Parameter type
User
Where set
User and $Resetn resettable (in subsystem only)
Related products
All
Introduced
Sirius Mods 8.0

Description

This is a bitmask parameter that helps collect diagnostics for problems caused by record locks in session objects. Since session objects can persist over extended periods, it is generally not a good idea to hold record locks in session objects.

The meaning of the SESDEBUG bits are:

X'01'
Issue message MSIR.1050 whenever a session is closed with exclusive record locks in session objects.
X'02'
Issue message MSIR.1051 whenever a session is closed with exclusive record locks in session objects, but undo the request cancellation normally caused by MSIR.1051. This allows a SirFact dump to be collected for the problem without actually causing the request to be canceled.
X'04'
Issue message MSIR.1051 whenever a session is closed with exclusive record locks in session objects. This allows a SirFact dump to be collected for the problem and then terminates the request and deletes the session, preventing the record locks from causing any lock conflicts.
X'10'
Issue message MSIR.1050 whenever a session is closed with any (share or exclusive) record locks in session objects.
X'20'
Issue message MSIR.1051 whenever a session is closed with any (share or exclusive) record locks in session objects, but undo the request cancellation normally caused by MSIR.1051. This allows a SirFact dump to be collected for the problem without actually causing the request to be canceled.
X'40'
Issue message MSIR.1051 whenever a session is closed with any (share or exclusive) record locks in session objects. This allows a SirFact dump to be collected for the problem and then terminates the request and deletes the session, preventing the record locks from causing any lock conflicts.

Notes

MSIR.1050 indicates the session object name that can be used to get to the object with the record lock and the strength of the lock. If multiple session objects can be used to get to multiple objects with record locks, only one is indicated by the message and the greatest lock strength is indicated.

Specifying lower bits is generally redundant. That is, there is no difference between SESDEBUG X'04', and X'05', and X'06', and X'07', the X'04' bit causes request cancellation on a detected exclusive record lock. Similarly, SESDEBUG X'22' and X'20' have identical meaning, they will both issue MSIR.1051 without cancelling the request for any record locks in session objects. SESDEBUG X'14' is different from X'10', however, because X'14' will cause request cancellation for an exclusive lock in a session object and a only a message for a share lock, while X'10' will only result in a message, regardless of the lock strength.