Available source records contain 7 distinct definitions; some records may not include a definition.
Show 7 published definitions
dbCreateTransaction · mandatory
dbCreateTransaction OBJECT-TYPE
SYNTAX INTEGER {
normal (1),
transaction (2),
verify (3),
done (6)}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"<Definition>This object provides transaction control for device configuration. The transaction mode changes the behavior of the agent to force buffering of database objects until all related database objects have been modified. In the normal mode, SET operations to any database object shall either be stored in a device's database immediately with no regard to whether other changes will be made or be rejected (as defined in the device-specific Information Profile). In the transaction mode, SET operations to any database object shall be buffered until a verify state performs a consistency check. When the consistency check completes, the device automatically transitions to the done state where a normal or transaction command may be issued.
A database object is a user provided piece of setup information (or it may be defined in an information profile) that is necessary for the proper operation of a device. It is static in nature in that the agent would never change it without direction from the management station. For example, a parameter that defines a default mode of operation would be a database object. A parameter that indicates the current state of the device would not be a database object.
The states and commands are defined as:
NORMAL: SET operations behave as normal SETs and shall have an immediate effect on the value of any database objects used by the device if none of the objects contained in the operation require the use of the transaction mode (as defined in the device-specific Information Profile). A SET operation containing any database object that requires the use of transaction mode shall result in a genErr. This is the default state of this object.
The only command that may be written to dbCreateTransaction while in this state is TRANSACTION. Any other values written to this object in this state shall result in an error response of 'badValue'.
TRANSACTION: A SET operation of one or more database objects that use the same community name as used in the request for the TRANSACTION state are buffered by the agent device for later consistency checks and a normal response is returned. A SET operation of one or more database objects using different community names shall result in a genErr with the index set to zero. A SET operation without a community name field (e.g., an STMP operation) shall be buffered by the agent device for later consistency checks and a normal response is returned. Standard SYNTAX checking shall take place at the time of the SET operation. A transaction may consist of multiple SET operations over multiple frames.
A SET operation for one or more non-database objects shall be processed as normal even if it uses another community name, except for this (i.e., the dbCreateTransaction) object.
A SET operation containing both database and non-database objects shall be processed in full according to these two rules. Thus, if it contains the same community name as used in the request for the TRANSACTION state, the non-database objects shall be stored immediately while the database objects shall be buffered. If it uses a different community name, the entire request will be rejected and a genErr with an index of zero shall be returned.
GET operations on any object shall return the values of the data stored in the controller and shall ignore any values contained in the buffer.
Any valid community name may read this (dbCreateTransaction) object when in this state, but only the community name used to command the object to the transaction mode and the administrator community name can set this object. A set from any other community name shall result in a genErr with an index of zero. The only commands that can be written to dbCreateTransaction while in this state are VERIFY and NORMAL. A VERIFY command will change the state to VERIFY. If a NORMAL command is received, all buffered data is discarded and the state is returned to NORMAL. Any other values written to this object when in this state shall result in an error response of 'badValue'.
VERIFY: Specific database objects are checked for consistency. When consistency checks are complete the device will automatically advance to the DONE state.
The state of dbCreateTransaction cannot be changed when in the VERIFY state. Any values written to this object in this state shall result in an error response of 'badValue'.
The consistency check analyzes certain critical objects 'in context' and treats them as an interrelated whole rather than separate non-related data items. The consistency check rules are not defined in this standard. They are device and implementation specific. Where applicable, the consistency check rules are defined in application specific object definition standards. A specific implementation may add additional checks beyond those defined in the standards.
A SET operation containing any database objects while in the VERIFY state shall result in a genErr with the index set to zero.
DONE: This state is entered automatically once consistency checks have completed in the VERIFY mode. The value of dbVerifyStatus and dbVerifyError indicate whether the consistency check found any errors.
A SET operation containing any database objects while in the DONE state shall result in a genErr with the index set to zero.
Any valid community name may read this (dbCreateTransaction) object when in this state, but only the community name used to command the object to the transaction mode and the administrator community name can set this object. A set from any other community name shall result in a genErr with an index of zero. The only commands that can be written to dbCreateTransaction while in this state are NORMAL and TRANSACTION. Any other values written to this object in this state shall result in an error response of 'badValue'.
If a NORMAL command is issued and dbVerifyStatus indicates doneWithNoError, the buffered data is transferred to the device memory and the state is returned to NORMAL. If a NORMAL command is issued and dbVerifyStatus indicates something other than doneWithNoError then the buffered data is discarded and the state is returned to NORMAL.
If a TRANSACTION command is issued, regardless of dbVerifyStatus, no action takes place (the buffered data is not changed) and the TRANSACTION state is re-entered.
COMMANDED STATE (9)
transaction
verify
normal
done
CURRENT
STATE
normal
transaction (1)
normal (2)
normal (2)
normal (2)
transaction
transaction (2)
verify (3)
normal (4)
transaction (2)
verify (7)
verify (2)
verify(2)
verify (2)
verify (2)
done (8)
transaction (5)
done(2)
normal (6)
done (2)Operational procedures and error responses:
(1) Once a copy of all database objects is placed in a buffer the state is changed to transaction and error response indicates noError. If the operation fails, the state remains the same and error response indicates genErr.
(2) No action takes place, the state remains the same, but response indicates badValue.
(3) The state is changed to verify, a consistency check is started, and response indicates noError. Once the consistency check is completed, the state automatically changes to done.
(4). The buffered copy of all database objects is discarded, the state is changed to normal, and response indicates noError.
(5) The buffered copy of all database objects is not changed or reloaded, the state is changed to transaction, and response indicates noError.
(6) If dbVerifyStatus indicates doneWithNoError, then the copy of all database objects is transferred to memory, the state is changed to normal and response indicates noError. If dbVerifyStatus indicates doneWithError then the buffered data is discarded, the state is changed to NORMAL, and response indicates noError.
(7) The state will automatically change to done when the consistency check completes.
(8) dbVerifyStatus and dbVerifyError are only valid in this state.
(9) All SET operations on this (dbCreateTransaction) parameter shall be made using a protocol that uses a community name, or equivalent field (e.g., SNMP).
<DescriptiveName>Transaction.mode:code
<DataConceptType>Data Element"
DEFVAL {normal}
::= { globalDBManagement 1 }dbCreateTransaction · deprecated
dbCreateTransaction OBJECT-TYPE
SYNTAX INTEGER { normal (1),
transaction (2),
verify (3),
done (6)
}
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"<Definition> This object provides transaction control for device configuration. The transaction mode changes the behavior of the agent to force buffering of parameter objects until all related parameter objects have been modified. In the normal mode, SET operations to any parameter object shall either be stored in a device's database immediately with no regard to whether other changes will be made or be rejected (as defined in the device-specific Information Profile). In the transaction mode, SET operations to any parameter object shall be buffered until a verify state performs a consistency check. When the consistency check completes, the device automatically transitions to the done state where a normal or transaction command may be issued.
A parameter object is a user-provided piece of setup information (or it may be defined in an information profile) that is necessary for the proper operation of a device. It is static in nature in that the agent would never change it without direction from the management station. For example, an object that defines a default mode of operation would be a parameter object. An object that indicates the current state of the device would not be a parameter object.
<Format>
The states and commands are defined as:
NORMAL: SET operations behave as normal SETs and shall have an immediate effect on the value of any parameter objects used by the device if none of the objects contained in the operation require the use of the transaction mode (as defined in the device-specific Information Profile). A SET operation containing any transaction object (i.e., a parameter object that requires the use of transaction mode) shall result in a genErr. This is the default state of this object.
The only command that may be written to dbCreateTransaction while in this state is TRANSACTION. Any other values written to this object in this state shall result in an error response of 'badValue'.
TRANSACTION: A SET operation of one or more parameter objects that use the same community name as used in the request for the TRANSACTION state are buffered by the agent device for later consistency checks and a normal response is returned. A SET operation of one or more parameter objects using different community names shall result in a genErr with the index set to zero. A SET operation without a community name field (e.g., an STMP operation) shall be buffered by the agent device for later consistency checks and a normal response is returned. Standard SYNTAX checking shall take place at the time of the SET operation. A transaction may consist of multiple SET operations over multiple frames.
A SET operation for one or more non-parameter objects shall be processed as normal even if it uses another community name, except for this (i.e., the dbCreateTransaction) object.
A SET operation containing both parameter and non-parameter objects shall be processed in full according to these two rules. Thus, if it contains the same community name as used in the request for the TRANSACTION state, the non-parameter objects shall be stored immediately while the parameter objects shall be buffered. If it uses a different community name, the entire request will be rejected and a genErr with an index of zero shall be returned.
GET operations on any object shall return the values of the data stored in the controller and shall ignore any values contained in the buffer.
Any valid community name may read this (dbCreateTransaction) object when in this state, but only the community name used to command the object to the transaction mode and the administrator community name can set this object. A set from any other community name shall result in a genErr with an index of zero. The only commands that can be written to dbCreateTransaction while in this state are VERIFY and NORMAL. A VERIFY command will change the state to VERIFY. If a NORMAL command is received, all buffered data is discarded and the state is returned to NORMAL. Any other values written to this object when in this state shall result in an error response of 'badValue'.
VERIFY: Specific parameter objects are checked for consistency. When consistency checks are complete the device will automatically advance to the DONE state.
The state of dbCreateTransaction cannot be changed when in the VERIFY state. Any values written to this object in this state shall result in an error response of 'badValue'.
The consistency check analyzes certain critical objects 'in context' and treats them as an interrelated whole rather than separate non-related data items. The consistency check rules are not defined in NTCIP 1201 v03, since these are device and implementation specific. Where applicable, the consistency check rules are defined in application specific object definition standards. A specific implementation may add additional checks beyond those defined in NTCIP standards.
A SET operation containing any parameter objects while in the VERIFY state shall result in a genErr with the index set to zero.
DONE: This state is entered automatically once consistency checks have completed in the VERIFY mode. The value of dbVerifyStatus and dbVerifyError indicate whether the consistency check found any errors.
A SET operation containing any parameter objects while in the DONE state shall result in a genErr with the index set to zero.
Any valid community name may read this (dbCreateTransaction) object when in this state, but only the community name used to command the object to the transaction mode and the administrator community name can set this object. A set from any other community name shall result in a genErr with an index of zero. The only commands that can be written to dbCreateTransaction while in this state are NORMAL and TRANSACTION. Any other values written to this object in this state shall result in an error response of 'badValue'.
If a NORMAL command is issued and dbVerifyStatus indicates doneWithNoError, the buffered data is transferred to the device memory and the state is returned to NORMAL. If a NORMAL command is issued and dbVerifyStatus indicates something other than doneWithNoError then the buffered data is discarded and the state is returned to NORMAL.
If a TRANSACTION command is issued, regardless of dbVerifyStatus, no action takes place (the buffered data is not changed) and the TRANSACTION state is re-entered.
COMMANDED STATE (9)
transaction
verify
normal
done
CURRENT
STATE
normal
transaction (1)
normal (2)
normal (2)
normal (2)
transaction
transaction (2)
verify (3)
normal (4)
transaction (2)
verify (7)
verify (2)
verify(2)
verify (2)
verify (2)
done (8)
transaction (5)
done(2)
normal (6)
done (2)
Operational procedures and error responses:
(1) Once a copy of all parameter objects is placed in a buffer, the state is changed to transaction and error response indicates noError. If the operation fails, the state remains the same and error response indicates genErr.
(2) No action takes place, the state remains the same, but response indicates badValue.
(3) The state is changed to verify, a consistency check is started, and response indicates noError. Once the consistency check is completed, the state automatically changes to done.
(4) The buffered copy of all parameter objects is discarded, the state is changed to normal, and response indicates noError.
(5) The buffered copy of all parameter objects is not changed or reloaded, the state is changed to transaction, and response indicates noError.
(6) If dbVerifyStatus indicates doneWithNoError, then the copy of all parameter objects is transferred to memory, the state is changed to normal and response indicates noError. If dbVerifyStatus indicates doneWithError then the buffered data is discarded, the state is changed to NORMAL, and response indicates noError.
(7) The state automatically changes to done when the consistency check completes.
(8) dbVerifyStatus and dbVerifyError are only valid in this state.
(9) All SET operations on this (dbCreateTransaction) parameter shall be made using a protocol that uses a community name, or equivalent field (e.g., SNMP).
<Superseded by> NTCIP1201v04-DB-MGMT.dbCreateTransactionV2
<Informative> The original version of this object referenced SNMPv1 error codes, community names, and an administrator name; the V2 object updates these details to be SNMPv3 specific.
<Object Identifier> 1.3.6.1.4.1.1206.4.2.6.2.1"
DEFVAL {normal}
::= { globalDBManagement 1 }dbCreateTransaction · unconfirmed
dbCreateTransaction OBJECT-TYPE
SYNTAX INTEGER { normal (1),
transaction (2),
verify (3),
done (6) }
MAX-ACCESS read-write
STATUS deprecated
DESCRIPTION
"<Definition> This object provides transaction control for device
configuration. The transaction mode changes the behavior of the agent to
force buffering of parameter objects until all related parameter objects
have been modified. In the normal mode, SET operations to any parameter
object shall either be stored in a device's database immediately with no
regard to whether other changes will be made or be rejected (as defined in
the device-specific Information Profile). In the transaction mode, SET
operations to any parameter object shall be buffered until a verify state
performs a consistency check. When the consistency check completes, the
device automatically transitions to the done state where a normal or
transaction command may be issued.
A parameter object is a user-provided piece of setup information (or it may
be defined in an information profile) that is necessary for the proper
operation of a device. It is static in nature in that the agent would never
change it without direction from the management station. For example, an
object that defines a default mode of operation would be a parameter
object. An object that indicates the current state of the device would not
be a parameter object.
<Format> The states and commands are defined as:
NORMAL: SET operations behave as normal SETs and shall have an immediate
effect on the value of any parameter objects used by the device if none of
the objects contained in the operation require the use of the transaction
mode (as defined in the device-specific Information Profile). A SET
operation containing any transaction object (i.e., a parameter object that
requires the use of transaction mode) shall result in a genErr. This is the
default state of this object.
The only command that may be written to dbCreateTransaction while in this
state is TRANSACTION. Any other values written to this object in this state
shall result in an error response of 'badValue'.
TRANSACTION: A SET operation of one or more parameter objects that use the
same community name as used in the request for the TRANSACTION state are
buffered by the agent device for later consistency checks and a normal
response is returned. A SET operation of one or more parameter objects
using different community names shall result in a genErr with the index set
to zero. A SET operation without a community name field (e.g., an STMP
operation) shall be buffered by the agent device for later consistency
checks and a normal response is returned. Standard SYNTAX checking shall
take place at the time of the SET operation. A transaction may consist of
multiple SET operations over multiple frames.
A SET operation for one or more non-parameter objects shall be processed as
normal even if it uses another community name, except for this (i.e., the
dbCreateTransaction) object.
A SET operation containing both parameter and non-parameter objects shall
be processed in full according to these two rules. Thus, if it contains the
same community name as used in the request for the TRANSACTION state, the
non-parameter objects shall be stored immediately while the parameter
objects shall be buffered. If it uses a different community name, the
entire request will be rejected and a genErr with an index of zero shall be
returned.
GET operations on any object shall return the values of the data stored in
the controller and shall ignore any values contained in the buffer.
Any valid community name may read this (dbCreateTransaction) object when in
this state, but only the community name used to command the object to the
transaction mode and the administrator community name can set this object.
A set from any other community name shall result in a genErr with an index
of zero. The only commands that can be written to dbCreateTransaction while
in this state are VERIFY and NORMAL. A VERIFY command will change the state
to VERIFY. If a NORMAL command is received, all buffered data is discarded
and the state is returned to NORMAL. Any other values written to this
object when in this state shall result in an error response of 'badValue'.
VERIFY: Specific parameter objects are checked for consistency. When
consistency checks are complete the device will automatically advance to
the DONE state.
The state of dbCreateTransaction cannot be changed when in the VERIFY
state. Any values written to this object in this state shall result in an
error response of 'badValue'.
The consistency check analyzes certain critical objects 'in context' and
treats them as an interrelated whole rather than separate non-related data
items. The consistency check rules are not defined in NTCIP 1201 v03, since
these are device and implementation specific. Where applicable, the
consistency check rules are defined in application specific object
definition standards. A specific implementation may add additional checks
beyond those defined in NTCIP standards.
A SET operation containing any parameter objects while in the VERIFY state
shall result in a genErr with the index set to zero.
DONE: This state is entered automatically once consistency checks have
completed in the VERIFY mode. The value of dbVerifyStatus and dbVerifyError
indicate whether the consistency check found any errors.
A SET operation containing any parameter objects while in the DONE state
shall result in a genErr with the index set to zero.
Any valid community name may read this (dbCreateTransaction) object when in
this state, but only the community name used to command the object to the
transaction mode and the administrator community name can set this object.
A set from any other community name shall result in a genErr with an index
of zero. The only commands that can be written to dbCreateTransaction while
in this state are NORMAL and TRANSACTION. Any other values written to this
object in this state shall result in an error response of 'badValue'.
If a NORMAL command is issued and dbVerifyStatus indicates doneWithNoError,
the buffered data is transferred to the device memory and the state is
returned to NORMAL. If a NORMAL command is issued and dbVerifyStatus
indicates something other than doneWithNoError then the buffered data is
discarded and the state is returned to NORMAL.
If a TRANSACTION command is issued, regardless of dbVerifyStatus, no action
takes place (the buffered data is not changed) and the TRANSACTION state is
re-entered.
| COMMANDED STATE (9)
|------------------------------------------------------------
CURRENT STATE | transaction | verify | normal | done
--------------+-----------------+------------+------------+----------------
normal | transaction (1) | normal (2) | normal (2) | normal (2)
transaction | transaction (2) | verify (3) | normal (4) | transaction (2)
verify (7) | verify (2) | verify (2) | verify (2) | verify (2)
done (8) | transaction (5) | done (2) | normal (6) | done (2)
Operational procedures and error responses:
(1) Once a copy of all parameter objects is placed in a buffer, the state
is changed to transaction and error response indicates noError. If the
operation fails, the state remains the same and error response indicates
genErr.
(2) No action takes place, the state remains the same, but response
indicates badValue.
(3) The state is changed to verify, a consistency check is started, and
response indicates noError. Once the consistency check is completed, the
state automatically changes to done.
(4) The buffered copy of all parameter objects is discarded, the state is
changed to normal, and response indicates noError.
(5) The buffered copy of all parameter objects is not changed or reloaded,
the state is changed to transaction, and response indicates noError.
(6) If dbVerifyStatus indicates doneWithNoError, then the copy of all
parameter objects is transferred to memory, the state is changed to normal
and response indicates noError. If dbVerifyStatus indicates doneWithError
then the buffered data is discarded, the state is changed to NORMAL, and
response indicates noError.
(7) The state automatically changes to done when the consistency check
completes.
(8) dbVerifyStatus and dbVerifyError are only valid in this state.
(9) All SET operations on this (dbCreateTransaction) parameter shall be
made using a protocol that uses a community name, or equivalent field
(e.g., SNMP).
<Supplanted by> ISO26048-1-Transaction.fdTransactionMode
<Informative> The original version of this object referenced SNMPv1 error
codes, community names, and an administrator name; the V2 object updates
these details to be SNMPv3 specific.
<Object Identifier> 1.3.6.1.4.1.1206.4.2.6.2.1"
DEFVAL { normal }
::= { globalDBManagement 1 }dbCreateTransaction · mandatory
dbCreateTransaction OBJECT-TYPE
SYNTAX INTEGER { normal (1),
transaction (2),
verify (3),
done (6)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"<Definition>This object provides transaction control for device
configuration. The transaction mode changes the behavior of the
agent to force buffering of database objects until all related
database objects have been modified. In the normal mode, SET
operations to any database object shall either be stored in a
device’s database immediately with no regard to whether other
changes will be made or be rejected (as defined in the device-
specific Information Profile). In the transaction mode, SET
operations to any database object shall be buffered until a verify
state performs a consistency check. When the consistency check
completes, the device automatically transitions to the done state
where a normal or transaction command may be issued.
A database object is a user provided piece of setup information
(or it may be defined in an information profile) that is necessary
for the proper operation of a device. It is static in nature in
that the agent would never change it without direction from the
management station. For example, a parameter that defines a
default mode of operation would be a database object. A parameter
that indicates the current state of the device would not be a
database object.
The states and commands are defined as:
NORMAL: SET operations behave as normal SETs and shall have an
immediate effect on the value of any database objects used by the
device if none of the objects contained in the operation require
the use of the transaction mode (as defined in the device-specific
Information Profile). A SET operation containing any database
object that requires the use of transaction mode shall result in a
genErr. This is the default state of this object.
The only command that may be written to dbCreateTransaction while
in this state is TRANSACTION. Any other values written to this
object in this state shall result in an error response of
‘badValue’.
TRANSACTION: A SET operation of one or more database objects that
use the same community name as used in the request for the
TRANSACTION state are buffered by the agent device for later
consistency checks and a normal response is returned. A SET
operation of one or more database objects using different
community names shall result in a genErr with the index set to
zero. A SET operation without a community name field (e.g., an
STMP operation) shall be buffered by the agent device for later
consistency checks and a normal response is returned. Standard
SYNTAX checking shall take place at the time of the SET operation.
A transaction may consist of multiple SET operations over multiple
frames.
A SET operation for one or more non-database objects shall be
processed as normal even if it uses another community name, except
for this (i.e., the dbCreateTransaction) object.
A SET operation containing both database and non-database objects
shall be processed in full according to these two rules. Thus, if
it contains the same community name as used in the request for the
TRANSACTION state, the non-database objects shall be stored
immediately while the database objects shall be buffered. If it
uses a different community name, the entire request will be
rejected and a genErr with an index of zero shall be returned.
GET operations on any object shall return the values of the data
stored in the controller and shall ignore any values contained in
the buffer.
Any valid community name may read this (dbCreateTransaction)
object when in this state, but only the community name used to
command the object to the transaction mode and the administrator
community name can set this object. A set from any other community
name shall result in a genErr with an index of zero. The only
commands that can be written to dbCreateTransaction while in this
state are VERIFY and NORMAL. A VERIFY command will change the
state to VERIFY. If a NORMAL command is received, all buffered
data is discarded and the state is returned to NORMAL. Any other
values written to this object when in this state shall result in
an error response of ‘badValue’.
VERIFY: Specific database objects are checked for consistency.
When consistency checks are complete the device will automatically
advance to the DONE state.
The state of dbCreateTransaction cannot be changed when in the
VERIFY state. Any values written to this object in this state
shall result in an error response of ‘badValue’.
The consistency check analyzes certain critical objects 'in
context' and treats them as an interrelated whole rather than
separate non-related data items. The consistency check rules are
not defined in this standard. They are device and implementation
specific. Where applicable, the consistency check rules are
defined in application specific object definition standards. A
specific implementation may add additional checks beyond those
defined in the standards.
A SET operation containing any database objects while in the VERIFY
state shall result in a genErr with the index set to zero.
DONE: This state is entered automatically once consistency checks
have completed in the VERIFY mode. The value of dbVerifyStatus
and dbVerifyError indicate whether the consistency check found any
errors.
A SET operation containing any database objects while in the DONE state
shall result in a genErr with the index set to zero.
Any valid community name may read this (dbCreateTransaction)
object when in this state, but only the community name used to
command the object to the transaction mode and the administrator
community name can set this object. A set from any other community
name shall result in a genErr with an index of zero. The only
commands that can be written to dbCreateTransaction while in this
state are NORMAL and TRANSACTION. Any other values written to
this object in this state shall result in an error response of
‘badValue’.
If a NORMAL command is issued and dbVerifyStatus indicates
doneWithNoError, the buffered data is transferred to the device
memory and the state is returned to NORMAL. If a NORMAL command
is issued and dbVerifyStatus indicates something other than
doneWithNoError then the buffered data is discarded and the state
is returned to NORMAL.
If a TRANSACTION command is issued, regardless of dbVerifyStatus,
no action takes place (the buffered data is not changed) and the
TRANSACTION state is re-entered.
COMMANDED STATE (9)
transaction verify normal done
normal transaction (1) normal (2) normal (2) normal (2)
CURRENT
transaction transaction (2) verify (3) normal (4) transaction (2)
STATE
verify (7) verify (2) verify(2) verify (2) verify (2)
done (8) transaction (5) done(2) normal (6) done (2)
Operational procedures and error responses:
(1) Once a copy of all database objects is placed in a
buffer the state is changed to transaction and error
response indicates noError. If the operation fails, the
state remains the same and error response indicates genErr.
(2) No action takes place, the state remains the same, but
response indicates badValue.
(3) The state is changed to verify, a consistency check is
started, and response indicates noError. Once the
consistency check is completed, the state automatically
changes to done.
(4). The buffered copy of all database objects is
discarded, the state is changed to normal, and response
indicates noError.
(5) The buffered copy of all database objects is not
changed or reloaded, the state is changed to transaction,
and response indicates noError.
(6) If dbVerifyStatus indicates doneWithNoError, then the
copy of all database objects is transferred to memory, the
state is changed to normal and response indicates noError.
If dbVerifyStatus indicates doneWithError then the buffered
data is discarded, the state is changed to NORMAL, and
response indicates noError.
(7) The state will automatically change to done when the
consistency check completes.
(8) dbVerifyStatus and dbVerifyError are only valid in this
state.
(9) All SET operations on this (dbCreateTransaction) parameter
shall be made using a protocol that uses a community name, or
equivalent field (e.g., SNMP).
<DescriptiveName>Transaction.mode:code
<DataConceptType>Data Element"
DEFVAL {normal}
::= { globalDBManagement 1 }dbCreateTransaction · mandatory
dbCreateTransaction OBJECT-TYPE
SYNTAX INTEGER { normal (1),
transaction (2),
verify (3),
done (6)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION
"<Definition>This object provides transaction control for device
configuration. The transaction mode changes the behavior of the
agent to force buffering of database objects until all related
database objects have been modified. In the normal mode, SET
operations to any database object shall either be stored in a
device’s database immediately with no regard to whether other
changes will be made or be rejected (as defined in the device-
specific Information Profile). In the transaction mode, SET
operations to any database object shall be buffered until a verify
state performs a consistency check. When the consistency check
completes, the device automatically transitions to the done state
where a normal or transaction command may be issued.
A database object is a user-provided piece of setup information
(or it may be defined in an information profile) that is necessary
for the proper operation of a device. It is static in nature in
that the agent would never change it without direction from the
management station. For example, a parameter that defines a
default mode of operation would be a database object. A parameter
that indicates the current state of the device would not be a
database object.
The states and commands are defined as:
NORMAL: SET operations behave as normal SETs and shall have an
immediate effect on the value of any database objects used by the
device if none of the objects contained in the operation require
the use of the transaction mode (as defined in the device-specific
Information Profile). A SET operation containing any database
object that requires the use of transaction mode shall result in a
genErr. This is the default state of this object.
The only command that may be written to dbCreateTransaction while
in this state is TRANSACTION. Any other values written to this
object in this state shall result in an error response of
‘badValue’.
TRANSACTION: A SET operation of one or more database objects that
use the same community name as used in the request for the
TRANSACTION state are buffered by the agent device for later
consistency checks and a normal response is returned. A SET
operation of one or more database objects using different
community names shall result in a genErr with the index set to
zero. A SET operation without a community name field (e.g., an
STMP operation) shall be buffered by the agent device for later
consistency checks and a normal response is returned. Standard
SYNTAX checking shall take place at the time of the SET operation.
A transaction may consist of multiple SET operations over multiple
frames.
A SET operation for one or more non-database objects shall be
processed as normal even if it uses another community name, except
for this (i.e., the dbCreateTransaction) object.
A SET operation containing both database and non-database objects
shall be processed in full according to these two rules. Thus, if
it contains the same community name as used in the request for the
TRANSACTION state, the non-database objects shall be stored
immediately while the database objects shall be buffered. If it
uses a different community name, the entire request will be
rejected and a genErr with an index of zero shall be returned.
GET operations on any object shall return the values of the data
stored in the controller and shall ignore any values contained in
the buffer.
Any valid community name may read this (dbCreateTransaction)
object when in this state, but only the community name used to
command the object to the transaction mode and the administrator
community name can set this object. A set from any other community
name shall result in a genErr with an index of zero. The only
commands that can be written to dbCreateTransaction while in this
state are VERIFY and NORMAL. A VERIFY command will change the
state to VERIFY. If a NORMAL command is received, all buffered
data is discarded and the state is returned to NORMAL. Any other
values written to this object when in this state shall result in
an error response of ‘badValue’.
VERIFY: Specific database objects are checked for consistency.
When consistency checks are complete the device will automatically
advance to the DONE state.
The state of dbCreateTransaction cannot be changed when in the
VERIFY state. Any values written to this object in this state
shall result in an error response of ‘badValue’.
The consistency check analyzes certain critical objects 'in
context' and treats them as an interrelated whole rather than
separate non-related data items. The consistency check rules are
not defined in NTCIP 1201 v03, since these are device and
implementation specific. Where applicable, the consistency check
rules are defined in application specific object definition
standards. A specific implementation may add additional checks
beyond those defined in NTCIP standards.
A SET operation containing any database objects while in the VERIFY
state shall result in a genErr with the index set to zero.
DONE: This state is entered automatically once consistency checks
have completed in the VERIFY mode. The value of dbVerifyStatus
and dbVerifyError indicate whether the consistency check found any
errors.
A SET operation containing any database objects while in the DONE state
shall result in a genErr with the index set to zero.
Any valid community name may read this (dbCreateTransaction)
object when in this state, but only the community name used to
command the object to the transaction mode and the administrator
community name can set this object. A set from any other community
name shall result in a genErr with an index of zero. The only
commands that can be written to dbCreateTransaction while in this
state are NORMAL and TRANSACTION. Any other values written to
this object in this state shall result in an error response of
‘badValue’.
If a NORMAL command is issued and dbVerifyStatus indicates
doneWithNoError, the buffered data is transferred to the device
memory and the state is returned to NORMAL. If a NORMAL command
is issued and dbVerifyStatus indicates something other than
doneWithNoError then the buffered data is discarded and the state
is returned to NORMAL.
If a TRANSACTION command is issued, regardless of dbVerifyStatus,
no action takes place (the buffered data is not changed) and the
TRANSACTION state is re-entered.
COMMANDED STATE (9)
transaction verify normal done
normal transaction normal (2) normal (2) normal (2)
(1)
transaction transaction verify (3) normal (4) transaction
CURRENT
STATE
(2) (2)
verify (7) verify (2) verify(2) verify (2) verify (2)
done (8) transaction done(2) normal (6) done (2)
(5)
Operational procedures and error responses:
(1) Once a copy of all database objects is placed in a
buffer, the state is changed to transaction and error
response indicates noError. If the operation fails, the
state remains the same and error response indicates genErr.
(2) No action takes place, the state remains the same, but
response indicates badValue.
(3) The state is changed to verify, a consistency check is
started, and response indicates noError. Once the
consistency check is completed, the state automatically
changes to done.
(4) The buffered copy of all database objects is discarded,
the state is changed to normal, and response indicates
noError.
(5) The buffered copy of all database objects is not
changed or reloaded, the state is changed to transaction,
and response indicates noError.
(6) If dbVerifyStatus indicates doneWithNoError, then the
copy of all database objects is transferred to memory, the
state is changed to normal and response indicates noError.
If dbVerifyStatus indicates doneWithError then the buffered
data is discarded, the state is changed to NORMAL, and
response indicates noError.
(7) The state automatically changes to done when the
consistency check completes.
(8) dbVerifyStatus and dbVerifyError are only valid in this
state.
(9) All SET operations on this (dbCreateTransaction) parameter
shall be made using a protocol that uses a community name, or
equivalent field (e.g., SNMP).
<Object Identifier> 1.3.6.1.4.1.1206.4.2.6.2.1"
DEFVAL {normal}
::= { globalDBManagement 1 }dbCreateTransaction · mandatory
dbCreateTransaction OBJECT-TYPE
SYNTAX INTEGER { normal (1),
transaction (2),
verify (3),
done (6)
}
ACCESS read-write
STATUS mandatory
DESCRIPTION:
"This object provides transaction control for device configuration. The transaction mode changes the
behavior of the agent to force buffering of database objects until all related database objects have been
modified. In the normal mode, SET operations to database objects may be stored in a device’s database
immediately with no regard to whether other changes will be made. In the transaction mode, SET
operations to database objects are buffered until a verify state performs a consistency check. When the
consistency check completes, the device automatically transitions to the done state where a normal or
transaction command can be issued.
A database object is a user provided piece of setup information that is necessary for the proper operation
of a device. It is static in nature in that the agent would never change it without direction from the
management station. For example, a parameter that defines a default mode of operation would be a
database object. A parameter that indicates the current state of the device would not be a database
object.
The states and commands are defined as:
NORMAL: SET operations behave as normal SNMP SETs and can have an immediate effect on the
value of any database objects used by the device. This is the default state of this object.
The only command that may be written to dbCreateTransaction while in this state is TRANSACTION.
Any other values written to this object in this state shall result in an error response of ‘badValue’.
TRANSACTION: SET operations of database objects are buffered by the agent device for later
consistency checks. Standard SYNTAX checking takes place at the time of the SET operation. A
transaction may consist of multiple SET operations over multiple frames.
The only commands that can be written to dbCreateTransaction while in this state are VERIFY and
NORMAL. A VERIFY command will change the state to VERIFY. If a NORMAL command is received, all
buffered data is discarded and the state is returned to NORMAL. Any other values written to this object
when in this state shall result in an error response of ‘badValue’.
VERIFY: Specific database objects are checked for consistency. When consistency checks are
complete the device will automatically advance to the DONE state.
The state of dbCreateTransaction cannot be changed when in the VERIFY state. Any other values
written to this object in this state shall result in an error response of ‘badValue’.
The consistency check analyzes certain critical objects ‘in context’ and treats them as an interrelated
whole rather than separate non-related data items. The consistency check rules are not defined in this
standard. They are device and implementation specific. Where applicable, the consistency check rules
are defined in application specific object definition standards. A specific implementation may add
additional checks beyond those defined in the standards. As a simplified example of a consistency
check, consider the following. Two objects are defined to specify the month and the day-of-month of an
event. Valid values for day-of-month would normally be 1 to 31, but in the context of month 9
(September), only the values 1 to 30 are correct.
DONE: This state is entered automatically once consistency checks have completed in the VERIFY
mode. The value of dbVerifyStatus and dbVerifyError indicate whether the consistency check found any
errors.
Only two valid values can be written to dbCreateTransaction in this state: NORMAL and TRANSACTION.
Any other values written to this object in this state shall result in an error response of ‘badValue’.
If a NORMAL command is issued and dbVerifyStatus indicates doneWithNoError, the buffered data is
transferred to the device memory and the state is returned to NORMAL. If a NORMAL command is
issued and dbVerifyStatus indicates something other than doneWithError then the buffered data is
discarded and the state is returned to NORMAL.
If a TRANSACTION command is issued, regardless of dbVerifyStatus, no action takes place (the buffered
data is not changed) and the TRANSACTION state is re-entered.
COMMANDED STATE
transaction verify normal done
normal transaction (1) normal (2) normal (2) normal (2)
transaction transaction (2) verify (3) normal (4) transaction (2)
CURRENT
STATE
verify (7) verify (2) verify(2) verify (2) verify (2)
done (8) transaction (5) done(2) normal (6) done (2)
Operational procedures and error responses:
(1) Once a copy of all database objects is placed in a buffer the state is changed to transaction
and error response indicates noError. If the operation fails, the state remains the same and error
response indicates genErr.
(2) No action takes place, the state remains the same, but response indicates badValue.
(3) The state is changed to verify, a consistency check is started, and response indicates
noError.
(4). The buffered copy of all database objects is discarded, the state is changed to normal, and
response indicates noError.
© 2001 NEMA Copy per MIB Distribution Notice
(5) The buffered copy of all database objects is not changed or reloaded, the state is changed to
transaction, and response indicates noError.
(6) If dbVerifyStatus indicates doneWithNoError, then the copy of all database objects is
transferred to memory, the state is changed to normal and response indicates noError. If
dbVerifyStatus indicates doneWithError then the buffered data is discarded, the state is changed
to NORMAL, and response indicates noError.
(7) The state will automatically change to done when the consistency check completes.
(8) dbVerifyStatus and dbVerifyError are only valid in this state."
::= { globalDBManagement 1 }vmsCharacterHeightPixels · unconfirmed
vmsCharacterHeightPixels OBJECT-TYPE
SYNTAX Integer32 (0..255)
UNITS "pixels"
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"<Definition> Indicates the height of a single character in pixels. The value
zero (0) indicates a variable character height, which implies a full-matrix
sign.
<Parameter Type> Status
<Object Identifier> 1.3.6.1.4.1.1206.4.2.3.2.1"
::= { vmsCfg 1 }