An entry describing a subscriber session job. At this time,
subscriber session jobs can perform one of two tasks:
- Subscriber Session Query
This type of job invokes the report generator, which builds
a list of subscriber sessions matching criteria specified by
the corresponding row in the csubJobMatchParamsTable. The
list built by the report generator must conform to
parameters specified by the corresponding row in
csubJobQueryParamsTable, which at this time only affects
sorting order.
- Subscriber Session Clear
This type of job causes the system to terminate those
subscriber sessions matching criteria specified by the
corresponding row in the csubJobMatchParamsTable.
The following procedure summarizes how the EMS/NMS can start and
monitor a subscriber session job:
1) The EMS/NMS must start by reading csubJobIdNext. If it is
zero, continue polling csubJobIdNext until it is non-zero.
2) The EMS/NMS creates a row in the csubJobTable using the
instance identifier retrieved in the last step. Since every
object contained by the entry with a MAX-ACCESS of
'read-create' specifies a default value, it makes little
difference whether the EMS/NMS employs create-and-wait or
create-and-go semantics.
3) The EMS/NMS sets the type of subscriber session job by
setting the corresponding instance of csubJobType.
4a) If the job is a 'query', then the EMS/NMS must configure
the query before starting it by setting columns contained
by the corresponding rows in the csubJobMatchParamsTable and
csubJobQueryParamsTable.
4b) If job is a 'clear', then the EMS/NMS must configure
the job before starting it by setting columns contained by
the corresponding row in the csubJobMatchParamsTable.
5) The EMS/NMS can now start the job by setting the
corresponding instance of csubJobControl to 'start'.
6) The EMS/NMS can monitor the progress of the job by polling
the corresponding instance of csubJobState. It can also
wait for a csubJobFinishedNotify notification. When the
state of the job transitions to 'finished', then the system
has finished executing the job.
7) The EMS/NMS can determine the final status of the job by
reading the corresponding instance of csubJobFinishedReason.
If job is a 'query' and the corresponding instance of
csubJobFinishedReason is 'normal', then the EMS/NMS can
safely read the report by retrieving the corresponding
rows from the csubJobReportTable.
8a) After a job has finished, the EMS/NMS has the option of
destroying it. It can do this by simply setting the
corresponding instance of csubJobStatus to 'destroy'.
Alternatively, the EMS/NMS may retain the job and execute it
again in the future (by returning to step 5). Additionally,
nothing would prevent the EMS/NMS from changing the job's
type, which causes the automatic destruction of the
corresponding report.
8b) If the job is a 'query' and the EMS/NMS opts to retain the
job, then it may consider releasing the corresponding report
after reading it. It can do this by setting the
corresponding instance of csubJobControl to 'release'.
An entry describing a subscriber session job. At this time,
subscriber session jobs can perform one of two tasks:
- Subscriber Session Query
This type of job invokes the report generator, which builds
a list of subscriber sessions matching criteria specified by
the corresponding row in the csubJobMatchParamsTable. The
list built by the report generator must conform to
parameters specified by the corresponding row in
csubJobQueryParamsTable, which at this time only affects
sorting order.
- Subscriber Session Clear
This type of job causes the system to terminate those
subscriber sessions matching criteria specified by the
corresponding row in the csubJobMatchParamsTable.
The following procedure summarizes how the EMS/NMS can start and
monitor a subscriber session job:
1) The EMS/NMS must start by reading csubJobIdNext. If it is
zero, continue polling csubJobIdNext until it is non-zero.
2) The EMS/NMS creates a row in the csubJobTable using the
instance identifier retrieved in the last step. Since every
object contained by the entry with a MAX-ACCESS of
'read-create' specifies a default value, it makes little
difference whether the EMS/NMS employs create-and-wait or
create-and-go semantics.
3) The EMS/NMS sets the type of subscriber session job by
setting the corresponding instance of csubJobType.
4a) If the job is a 'query', then the EMS/NMS must configure
the query before starting it by setting columns contained
by the corresponding rows in the csubJobMatchParamsTable and
csubJobQueryParamsTable.
4b) If job is a 'clear', then the EMS/NMS must configure
the job before starting it by setting columns contained by
the corresponding row in the csubJobMatchParamsTable.
5) The EMS/NMS can now start the job by setting the
corresponding instance of csubJobControl to 'start'.
6) The EMS/NMS can monitor the progress of the job by polling
the corresponding instance of csubJobState. It can also
wait for a csubJobFinishedNotify notification. When the
state of the job transitions to 'finished', then the system
has finished executing the job.
7) The EMS/NMS can determine the final status of the job by
reading the corresponding instance of csubJobFinishedReason.
If job is a 'query' and the corresponding instance of
csubJobFinishedReason is 'normal', then the EMS/NMS can
safely read the report by retrieving the corresponding
rows from the csubJobReportTable.
8a) After a job has finished, the EMS/NMS has the option of
destroying it. It can do this by simply setting the
corresponding instance of csubJobStatus to 'destroy'.
Alternatively, the EMS/NMS may retain the job and execute it
again in the future (by returning to step 5). Additionally,
nothing would prevent the EMS/NMS from changing the job's
type, which causes the automatic destruction of the
corresponding report.
8b) If the job is a 'query' and the EMS/NMS opts to retain the
job, then it may consider releasing the corresponding report
after reading it. It can do this by setting the
corresponding instance of csubJobControl to 'release'.
csubJobEntry OBJECT-TYPE SYNTAX CsubJobEntry ACCESS not-accessible STATUS mandatory DESCRIPTION "An entry describing a subscriber session job. At this time, subscriber session jobs can perform one of two tasks: - Subscriber Session Query This type of job invokes the report generator, which builds a list of subscriber sessions matching criteria specified by the corresponding row in the csubJobMatchParamsTable. The list built by the report generator must conform to parameters specified by the corresponding row in csubJobQueryParamsTable, which at this time only affects sorting order. - Subscriber Session Clear This type of job causes the system to terminate those subscriber sessions matching criteria specified by the corresponding row in the csubJobMatchParamsTable. The following procedure summarizes how the EMS/NMS can start and monitor a subscriber session job: 1) The EMS/NMS must start by reading csubJobIdNext. If it is zero, continue polling csubJobIdNext until it is non-zero. 2) The EMS/NMS creates a row in the csubJobTable using the instance identifier retrieved in the last step. Since every object contained by the entry with a MAX-ACCESS of 'read-create' specifies a default value, it makes little difference whether the EMS/NMS employs create-and-wait or create-and-go semantics. 3) The EMS/NMS sets the type of subscriber session job by setting the corresponding instance of csubJobType. 4a) If the job is a 'query', then the EMS/NMS must configure the query before starting it by setting columns contained by the corresponding rows in the csubJobMatchParamsTable and csubJobQueryParamsTable. 4b) If job is a 'clear', then the EMS/NMS must configure the job before starting it by setting columns contained by the corresponding row in the csubJobMatchParamsTable. 5) The EMS/NMS can now start the job by setting the corresponding instance of csubJobControl to 'start'. 6) The EMS/NMS can monitor the progress of the job by polling the corresponding instance of csubJobState. It can also wait for a csubJobFinishedNotify notification. When the state of the job transitions to 'finished', then the system has finished executing the job. 7) The EMS/NMS can determine the final status of the job by reading the corresponding instance of csubJobFinishedReason. If job is a 'query' and the corresponding instance of csubJobFinishedReason is 'normal', then the EMS/NMS can safely read the report by retrieving the corresponding rows from the csubJobReportTable. 8a) After a job has finished, the EMS/NMS has the option of destroying it. It can do this by simply setting the corresponding instance of csubJobStatus to 'destroy'. Alternatively, the EMS/NMS may retain the job and execute it again in the future (by returning to step 5). Additionally, nothing would prevent the EMS/NMS from changing the job's type, which causes the automatic destruction of the corresponding report. 8b) If the job is a 'query' and the EMS/NMS opts to retain the job, then it may consider releasing the corresponding report after reading it. It can do this by setting the corresponding instance of csubJobControl to 'release'." INDEX { csubJobId } ::= { csubJobTable 1 }
csubJobEntry OBJECT-TYPE SYNTAX CsubJobEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a subscriber session job. At this time, subscriber session jobs can perform one of two tasks: - Subscriber Session Query This type of job invokes the report generator, which builds a list of subscriber sessions matching criteria specified by the corresponding row in the csubJobMatchParamsTable. The list built by the report generator must conform to parameters specified by the corresponding row in csubJobQueryParamsTable, which at this time only affects sorting order. - Subscriber Session Clear This type of job causes the system to terminate those subscriber sessions matching criteria specified by the corresponding row in the csubJobMatchParamsTable. The following procedure summarizes how the EMS/NMS can start and monitor a subscriber session job: 1) The EMS/NMS must start by reading csubJobIdNext. If it is zero, continue polling csubJobIdNext until it is non-zero. 2) The EMS/NMS creates a row in the csubJobTable using the instance identifier retrieved in the last step. Since every object contained by the entry with a MAX-ACCESS of 'read-create' specifies a default value, it makes little difference whether the EMS/NMS employs create-and-wait or create-and-go semantics. 3) The EMS/NMS sets the type of subscriber session job by setting the corresponding instance of csubJobType. 4a) If the job is a 'query', then the EMS/NMS must configure the query before starting it by setting columns contained by the corresponding rows in the csubJobMatchParamsTable and csubJobQueryParamsTable. 4b) If job is a 'clear', then the EMS/NMS must configure the job before starting it by setting columns contained by the corresponding row in the csubJobMatchParamsTable. 5) The EMS/NMS can now start the job by setting the corresponding instance of csubJobControl to 'start'. 6) The EMS/NMS can monitor the progress of the job by polling the corresponding instance of csubJobState. It can also wait for a csubJobFinishedNotify notification. When the state of the job transitions to 'finished', then the system has finished executing the job. 7) The EMS/NMS can determine the final status of the job by reading the corresponding instance of csubJobFinishedReason. If job is a 'query' and the corresponding instance of csubJobFinishedReason is 'normal', then the EMS/NMS can safely read the report by retrieving the corresponding rows from the csubJobReportTable. 8a) After a job has finished, the EMS/NMS has the option of destroying it. It can do this by simply setting the corresponding instance of csubJobStatus to 'destroy'. Alternatively, the EMS/NMS may retain the job and execute it again in the future (by returning to step 5). Additionally, nothing would prevent the EMS/NMS from changing the job's type, which causes the automatic destruction of the corresponding report. 8b) If the job is a 'query' and the EMS/NMS opts to retain the job, then it may consider releasing the corresponding report after reading it. It can do this by setting the corresponding instance of csubJobControl to 'release'." INDEX { csubJobId } ::= { csubJobTable 1 }
| OID | Name | Sub children | Sub Nodes Total | Description |
|---|---|---|---|---|
| 1.3.6.1.4.1.9.9.786.1.3.7.1.1 | csubJobId | 0 | 0 | This object indicates an arbitrary, positive integer-value uniquely identifying the subscriber session job. |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.2 | csubJobStatus | 0 | 0 | This object specifies the status of the subscriber session job. The following columns must be valid before activating a subscrib… |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.3 | csubJobStorage | 0 | 0 | This object specifies what happens to the subscriber session job upon restart. |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.4 | csubJobType | 0 | 0 | This object specifies the type of subscriber session job: 'noop' This type of job does nothing and simply serves as a convenient d… |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.5 | csubJobControl | 0 | 0 | This object specifies an action relating to the subscriber session job: 'noop' This action does nothing. 'start' If the correspondin… |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.6 | csubJobState | 0 | 0 | This object indicates the current state of the subscriber session job: 'idle' This state indicates that the system has not execute… |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.7 | csubJobStartedTime | 0 | 0 | This object indicates the value of sysUpTime when the system started executing the subscriber session job. This value will be '0… |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.8 | csubJobFinishedTime | 0 | 0 | This object indicates the value of sysUpTime when the system finished executing the subscriber session job, for whatever reason. … |
| 1.3.6.1.4.1.9.9.786.1.3.7.1.9 | csubJobFinishedReason | 0 | 0 | This object indicates the reason why the system finished executing the subscriber session job: 'invalid' Indicates that the corres… |