The NetIQctrl command-line program is an interactive program that allows you to view current activity and configuration settings for specified computers. It is used primarily for diagnostic analysis and troubleshooting.
Most of the information available through NetIQctrl commands is also available by clicking TreeView > Troubleshooter in the Operator Console. The command output is identical to what’s displayed in the Troubleshooter Information pane. However, some report options are only available from the command line using NetIQctrl.
You can start the NetIQctrl program from the AppManager Operator Console by clicking Extensions > NetIQCtrl, or from a Command Prompt window by running the executable NetIQctrl.exe (located in the AppManager bin directory).
Once you start the NetIQctrl program, you enter commands on the command line. The general format for NetIQCtrl commands is:
command hostname component [options …]
|
Parameter |
Description |
|---|---|
|
command |
One of the available NetIQCtrl commands. |
|
hostname |
The name or IP address of the computer where the AppManager management server or agent is running. In the syntax descriptions:
|
|
component |
The appropriate AppManager component.
Some commands can apply for more than one component, but you can only retrieve information for one component at a time. In addition, some commands require you to use a keyword in the command line to control the information retrieved. |
|
[options …] |
One or more optional parameters, such as a job ID number, that limit or refine the type of information that the command displays. |
The following table lists the NetIQctrl commands and describes how to use them. Most commands include an example of the output they produce. These examples are only intended to illustrate the type of information returned. You may see different or additional information when you run these commands.
|
Command |
Description |
|---|---|
|
debug |
Sets a debug category and level to start tracing activity on a management server or an agent computer. The debug command is for diagnostic purposes only and is therefore of primary interest to programmers who are developing custom Knowledge Scripts. The categories and levels you specify depend on the component, NetIQmc or NetIQms, you want to trace. The higher you set the debugging level, the more verbose the debugging output. The basic syntax is: debug mc_hostname NetIQmc debug_category debug_level debug ms_hostname NetIQms debug_category debug_level For example, to set moderate tracing for the AppManager agent on the agent computer shasta, use: debug shasta NetIQmc MC_ALL 256 To control where tracing output is sent, use the output command. For a list of tracing categories and levels, use the info command. |
|
dictget |
Displays Server-Side Job Configuration (SSJC) parameters from an agent's local repository. The basic syntax is: dictget mc_hostname NetIQmc [ms_host] param_name|get_all You can retrieve:
To retrieve Server-Side Job Configuration parameters associated with a specific AppManager repository, specify the name of a management server that communicates with that repository. For example, if the agent computer starlet is managed by two management servers, sunset and venice, with data and events stored in separate repositories, you may want to specify which repository you are interested in by including the management server name in the command line: dictget starlet NetIQmc venice get_all Output example Results for site VENICE1029277802_1029277802: _NQ_LogicalDisk_DriveList = c:,d: _NQ_LogicalDisk_TH_FREE = 10 _NQ_LogicalDisk_TH_READS = 50 _NQ_LogicalDisk_TH_UTIL = 90 _NQ_LogicalDisk_TH_WRITES = 50 _NQ_LogicalDisk_TH_XFERS = 80 _NQ_Service_ExcludeList = _NQ_Service_ServiceList = EventLog |
|
exit |
Exits NetIQctrl. The basic syntax is: exit |
|
healthcheck |
Verifies that the job information stored in the AppManager repository is in sync with the agent’s job information. Under normal conditions, the agent sends its job list to the management server periodically and the management server compares this list to the job list stored in the repository to ensure they are the same. This command allows you to check this activity. This command provides the following information:
This command can be useful if you are trying to determine whether changes to job status or the job list are being handled properly for an agent computer. For example, if a job appears to remain in a Pending state or has been stopped but still appears to be running in the Operator Console, you can use this command to see the time of the last status check by the management server and the list of active jobs from the repository and the agent. The basic syntax is: healthcheck ms_hostname NetIQms mc_hostname Output example --------------------------- Health Check Info --------------------------- Last Health Check Time: 1029354749 Job List from Repository: 12 18 20 22 Job List from Agent: 22 18 20 12 Last Job Check Time: 1029269190 Job List to Agent: 22 Number of Jobs in Cache: 0 Job List in Cache: None |
|
help |
Displays the list of commands and usage information for NetIQctrl. The basic syntax is: help You can also use a question mark (?) to display help. |
|
info |
Displays a list of symbol-to-number mappings that can be used with the debug command to set the category and level of tracing information returned from a Knowledge Script while it is running. The basic syntax is: info Output example (Tracing Categories) MC_CORE, 65 MC_RPC, 66 MC_VBA, 67 MC_CALLBACK, 68 MC_REPOSITORY, 69 MS_MS, 85 MS_MC, 86 MS_RP, 87 ------- (Tracing Levels) LEVEL_VERBOSE, 65535 LEVEL_TRACE, 256 LEVEL_CRITICAL, 64 When specifying the debug category or level, you can use either the symbol (such as MC_CORE or LEVEL_VERBOSE) or the number mapping (such as 65 or 65535). For example, to start tracing for the agent computer named shasta, you can use either: debug shasta netiqmc MC_VBA LEVEL_TRACE or debug shasta netiqmc 67 256 To control where tracing output is sent, use the output command. |
|
infoconfig |
Displays configuration information for a management server. Some configuration parameters, such as polling intervals, control the behavior of a management server and can be used to fine-tune its performance. The basic syntax is: infoconfig ms_hostname NetIQms
For example, to list the configuration for the management server olympus, use: infoconfig olympus netiqms Output example ----------------------------------------------------
MS Configuration Info
----------------------------------------------------
** connectivity
MS Port : 9999
MC Port : 9998
rpc comm wait : 5000
ccm flow ctrl : enabled
** execution
mode : service
start time : Tue Aug 13 10:04:53 2002
** repository
server : OLYMPUS
site name : OLYMPUS1028146695
repository name : QDB
ms UUID : c6ebacea-50d9-4e73-8e0f-f7654c713
dsn : QDBms
user name : netiq
machine id : 34
machine name : OLYMPUS
wait on rp failure : 300
rp retry : 0
** ioc threads
data worker : 2
event worker : 1
** thread sleep intervals
job poll : 5
job stat : 300
job stat ip refresh : 1000
unix machine check : 300
unix machine timeout: 600
machine poll : 900
machine ping : 5
all machines ping : 0
** event config
record type : create open events (default)
cache list max : 10
collapsed ioc retry : 1
** data config
data batching : on
data retry : 1 |
|
job |
Displays a summary of the jobs on an agent computer. For more detailed job information, use the profile command. The job command is useful for verifying the state of a job. For example, if a job appears in Pending state in the Operator Console, you can use the job command to determine whether the job has started on the agent computer. If the job has started on the agent computer but the Operator Console shows it as pending, you would want to investigate the connections between the agent computer, the management server, and the repository. The basic syntax is: job mc_hostname NetIQmc [option]
Use the optional parameter to specify the type of job you want to display:
You can check the status of a specific job by specifying the management server name that started the job and the job ID. To see a list of all jobs on the agent computer named paris, use: job paris NetIQmc Output example ---------------------- Running Jobs ---------------------- 22_AJAX1028146695_1028146695 : thread=2012 15 <worker running> <sleeping> 18_AJAX1028146695_1028146695 : thread=2144 15 <worker running> <sleeping> 20_AJAX1028146695_1028146695 : thread=768 3 <worker running> <sleeping> 12_AJAX1028146695_1028146695 : thread=1652 14 <worker running> <sleeping> ------------------------------- Stopped/Completed Jobs ------------------------------- 40_AJAX1028146695_1028146695 : Wed Aug 14 11:52:23 2002 42_AJAX1028146695_1028146695 : Wed Aug 14 11:56:30 2002 +++++++ total 2 completed jobs +++++++ total 4 running jobs |
|
jobevt |
Displays event summary information for all jobs or for a specific job on an agent computer. The jobevt command is useful for verifying the number of events generated by a specific job. For example, you might compare the number of events reported by the jobevt command with the number of events displayed in the Operator Console for that job. If the numbers don’t match, you might want to investigate the connections between the agent computer, the management server, and the repository. For detailed event collapsing information, use the profevt command. The basic syntax is: jobevt mc_hostname NetIQmc [ms_hostname job_id] The optional parameters let you specify a job ID. To identify a specific job, you must also provide the name of the management server that started the job. For example, to see the event collapsing information for job number 20, which is running on the agent computer named shasta and was scheduled by the management server ajax, use: jobevt shasta netiqmc ajax 20 Output example ---------------------- Running Jobs ---------------------- Job [20] => KS Name : 1702:NT_LogicalDiskBusy QDB Site : AJAX1028146695_1028146695 QDB Site UpdTime : 1028146695 MS machine : AJAX <10.5.10.92> Collapse Intv : 1200 sec Occur Interval : 1 [1029258286_2] inst 5 non_collapse 5 collapse 0 (cur=0) Job [12] => KS Name : 1702:General_ServiceDown QDB Site : AJAX1028146695_1028146695 QDB Site UpdTime : 1028146695 MS machine : AJAX <10.5.10.92> Collapse Intv : 1200 sec Occur Interval : 1 [1029258286_5] inst 1 non_collapse 1 collapse 24 (cur=24) +++++++ total 2 running jobs |
|
jobmod |
Indicates the time of the last modification to a job’s properties. The modification time is displayed in UTC format. The basic syntax is: jobmod ms_hostname NetIQms job_id Output example --------------------------- Job Modification Info --------------------------- job id: 4 last mod time (utc): 1029432427 last status: 513 |
|
jobrsc |
Displays status information for jobs that are inactive on an agent computer during a maintenance period. Maintenance periods are set by Knowledge Script category. The jobrsc command includes standard job information, a resource ID for each Knowledge Script category running on the agent computer, the number of job iterations skipped because of maintenance, and the last time an iteration was skipped. The jobrsc command is useful for determining how many times a job has not run because of a maintenance period. For example, you may be trying to discover why a job has not generated the expected number of data points. You can use the jobrsc command to determine how many times the job did not run, which could explain why fewer data points were collected. The basic syntax is: jobrsc mc_hostname NetIQmc [ms_hostname job_id] Optional parameters let you specify a job ID. To identify a specific job, provide the name of the management server that scheduled it. For example, to display information about skipped iterations for all jobs on the agent computer named shasta: jobrsc shasta NetIQmc Output example ---------------------- Running Jobs ---------------------- Job [62] => KS Name : NT_CpuResource QDB Site : OLYMPUS904955486_904955487 QDB Site UpdTime : 904955487 MS machine : OLYMPUS <10.1.10.65> Job Status : worker running RSC ID : 0 # Skipped Iter : 0 Iter Skip Time : Job [66] => KS Name : SQL_DataSpace QDB Site : OLYMPUS904955486_904955487 QDB Site UpdTime : 904955487 MS machine : OLYMPUS <10.1.10.65> Job Status : Inactive RSC ID : 1 # Skipped Iter : 18 Iter Skip Time : Tue Sep 10 14:46:40 2002 +++++++ total 2 running jobs |
|
jobsched |
Displays scheduling information for a specific job. Basic syntax: jobsched mc_hostname NetIQmc ms_hostname job_id For example, to see scheduling information for job ID 68, which is running on the agent computer named shasta and was scheduled by the management server named olympus, use: jobsched shasta netiqmc olympus 68 Output example -------------------------- Job Scheduling Info -------------------------- Job [68__OLYMPUS904955486_904955487] ==> Type: on demand Recur Type: INTERVAL ITERATION Interval: 5 min |
|
jobstat |
Displays statistics for a specific job running on an agent computer. For example, jobstat displays the number of events, data headers, data points, and agent computer actions generated by the job. The basic syntax is: jobstat mc_hostname NetIQmc ms_hostname job_id For example, to display information for job number 62, running on the agent computer shasta and was scheduled by the management server olympus, use: jobstat shasta netiqmc olympus 62 Output example Job [62_OLYMPUS904955486_904955487] =>
#-Generated #-Failed
---------- ----------- ----------
Event 4 0
CtrlEvt 1344 0
DataHead 1 0
DataLog 22 0
MCAction 0 0 |
|
ks |
Displays the Knowledge Script of a specified job that is currently running on an agent computer. The basic syntax is: ks mc_hostname NetIQmc ms_hostname job_id NOTE:This command is not supported for version 4.0 and later Knowledge Scripts. |
|
listfc |
Displays the current network configuration and flow control information between an agent computer and the management server that it is communicating with. The basic syntax is: listfc mc_hostname NetIQccm site|ms ms_hostname
The information returned should be the same, whether you use the site or ms keyword. For example, to see network configuration and flow control information between the agent computer named shasta and the management server named olympus, use: listfc shasta netiqccm site olympus Output example ----------------------------------------------
List CCM Current Site Network Info
----------------------------------------------
netsrv thread id 2460
MS hostname OLYMPUS <10.5.111.139>
MS network status up
Communication mode uploadInProcess
Current high watermark 100 kb
Current low watmermark 0 kb
Current batching interval 1000 sec
Last net transaction Time Thu Aug 15 12:23:20 2002 |
|
listms |
Displays a list of all management servers that are communicating with a specified agent computer. The list indicates the number of running jobs that were started from each management server and the state of the connection between the agent computer and each management server. The basic syntax is: listms mc_hostname NetIQmc For example, to see information about the management servers that communicate with the agent computer named paris, use: listms paris netiqmc Output example ----------------------------------------------
List MS
----------------------------------------------
OLYMPUS1029277802_1029277802
Current MS => 10.5.11.39 OLYMPUS
Job Refcnt => 3
Use MS IP => 1
MS status => Up
Send via => ccm
AJAX1029363296_1029363296
Current MS => 10.5.10.92 AJAX
Job Refcnt => 2
Use MS IP => 1
MS status => Down
Send via => ccm
This example indicates that the agent computer paris communicates with two management servers, olympus and ajax. Three jobs were submitted from the management server olympus and two jobs were submitted by the management server ajax. Because communication between the agent computer and the management server ajax is down, data and events for the two jobs submitted by ajax are being stored locally on the agent computer. Data and events from the three jobs submitted by olympus are being uploaded via the Client Communication Manager because communication between that management server and agent computer is working correctly. The Use MS IP parameter indicates whether the communication between the agent computer and management server is established using the management server’s IP address or hostname. A value of 1 indicates the communication uses the management server’s IP address. A value of 0 indicates communication is established using the hostname. |
|
listrsc |
Displays a list of all categories of jobs running on a agent computer and indicates which categories are affected by scheduled maintenance periods. Each job category is identified by a resource ID. The resource ID is specific to each agent computer. For example, if two SQL Knowledge Scripts are running on an agent computer, both jobs will have the same resource ID. However, that resource ID for SQL Server jobs on that agent computer will not necessarily match the resource ID for SQL Server jobs on other agent computers. For each category of Knowledge Script affected by a scheduled maintenance, the jobrsc command provides additional detail about the maintenance period. The basic syntax is: listrsc mc_hostname NetIQmc For example, to display a list of all categories of Knowledge Scripts running on the agent computer named shasta: listrsc shasta netiqmc Output example ---------------------
RSC Info
-----------------------
<RSC #0> :
Name => NT
JobCnt => 2
Status => NotScheduled
ResDepend =>
SvcDepend =>
<RSC #1> :
Name => SQL
JobCnt => 1
Status => Inactive
ResDepend =>
SvcDepend =>
#-KPC-#
Type: scheduled
Recur Type: DAILY
Recur Freq: every <1> day(s)
Start Time: 14:00:00
End Time: 17:59:00
Interval: 5 min |
|
listsite |
Displays a list of all QDBs monitoring an agent computer. The basic syntax is: listsite mc_hostname NetIQccm For example, to list all the QDBs that are monitoring the agent computer named paris, use: listsite paris netiqccm Output example ----------------------------------------------
List CCM Site Info
----------------------------------------------
[SITE #1]
QDB Name VENICE1029277802_1029277802
QDB Key 32c368bf-36a0-401f-b64c-5ee5547cc689
QDB Updtime 1029277802
MS hostname VENICE <10.5.11.52>
CCM comm id 3
Server thread id 1060
Startup Time Wed Aug 14 14:19:07 2002
Reference Count 1
[SITE #2]
QDB Name LONDON1028151606_1028151607
QDB Key ae215a98-dbdb-4d9f-a13e-22b8a33a083d
QDB Updtime 1028151607
MS hostname LONDON <10.5.18.42>
CCM comm id 2
Server thread id 1560
Startup Time Fri Aug 02 11:30:52 2002
Reference Count 1
[SITE #3]
QDB Name MILAN1027112432_1027112433
QDB Key dfdb0224-fef3-4e51-b05d-5454ae4034f6
QDB Updtime 1027112433
MS hostname MILAN <10.5.11.61>
CCM comm id 1
Server thread id 1012
Startup Time Thu Jul 25 17:09:28 2002
Reference Count 1 |
|
listupload |
Lists the scheduled upload status that a QDB has registered with the Client Communication Manager service on an agent computer. This command lists the upload status of both events and data. The basic syntax is: listupload mc_hostname NetIQccm site|ms ms_hostname
The information returned should be the same, whether you use the site or ms keyword. For example, to list upload information for the agent computer named paris and the management server on the computer named olympus, use: listupload paris netiqccm site olympus Output example ----------------------------------------------
List CCM Site Upload Configuration
----------------------------------------------
QDB Site Name OLYMPUS1029277802_1029277802
QDB Site Updtime 1029277802
MS hostname OLYMPUS <10.5.11.39>
Event Upload active
Data Upload active |
|
machine |
Displays computer- or monitoring-related information that a management server has collected for all agent computers or a specified agent computer. The information displayed includes:
The basic syntax is: machine ms_hostname NetIQms [mc_hostname] If you do not specify a specific agent computer, the machine command displays cached information for all agent computers that the management server is currently aware of. Because this operation is more expensive in terms of system resources, it is usually better to specify a specific agent computer. For example, to display the information that the management server named olympus has cached at the agent computer named paris, use: machine olympus netiqms paris Output example: ---------------------------------------------------- MS Cached Machine Info ---------------------------------------------------- PARIS: ** connectivity rpc comm version : 2.4.0 last ping success : Thu Aug 15 11:47:39 2002 last ping fail : Tue Aug 13 15:47:31 2002 ** jobs last job status success : Tue Aug 13 16:02:31 2002 last job status fail : none start requests submitted : 9 stop requests submitted : 1 current job request : 0 time job submitted : Wed Aug 14 15:41:03 2002 jobs skipped : 0 ** time zone name : Pacific Standard Time daylight savings name : Pacific Daylight Time bias : 28800 active bias : 25200 daylight savings : applicable |
|
netconf |
Lists the user-specified network configuration that a specific QDB or management server has registered with the Client Communication Manager (NetIQccm) service on an agent computer. The information includes the flow control configuration and the communication type. The basic syntax is: netconf mc_hostname NetIQccm site|ms ms_hostname
For example, to display the network configuration information that the management server named olympus has registered with the agent computer named paris, use: netconf paris netiqccm site olympus Output example: -----------------------------------------------
List CCM Site Network Configuration
-----------------------------------------------
MS hostname OLYMPUS <10.5.11.39>
RPC connection caching disabled
Communication type ipaddr
Communication encryption Off
Communication mode uploadScheduled
Net high watermark 100 kb
Net low watermark 0 kb
Net batching interval 1000 sec
Dynamic Flow Control disabled |
|
output |
Specifies where to send the debug tracing output collected from a agent computer or management server. The basic syntax is: output mc_hostname NetIQmc [option] output ms_hostname NetIQmc [option] Optional parameters turn tracing off or direct output:
For example, to direct tracing for the AppManager agent on the agent computer named shasta to the file trace.txt, use: output shasta NetIQmc file trace.txt To view tracing for the AppManager agent on the agent computer named shasta in the NetIQctrl window, use: output shasta NetIQmc here Output example: NetIQctrl> 10.1.1.163: [484] MCRunJob: finished processing job <45_SHASTA880588204>, ms=<10.1.1.163> NOTE:The debugging output will be intermixed with your commands. |
|
ping |
Checks connectivity and displays version and configuration information for an agent computer or a management server. If a connection is made, the ping command displays the version number and startup information for the AppManager service running on the specified computer. The basic syntax is: ping mc_hostname NetIQmc [ext] ping ms_hostname NetIQms The optional ext keyword displays extended configuration for the agent computer. The additional information indicates whether the agent is running in autonomous mode, whether data persistence is enabled, the communication protocol for the local repository and for the management server, and how tracing is configured. For example, to check whether the AppManager agent is running on the agent computer named shasta, use: ping shasta NetIQmc Output example: version 4.6.31.0 start_mode Service start_time Wed Aug 14 15:25:16 2002 trace_level 1 rpc version 4.0 rpc port # 9998 If the AppManager agent isn’t running on shasta, you see: Failed to connect to mc NOTE:Generally, the AppManager agent uses port 9998, and the management server uses port 9999. |
|
probe |
Sends a probe request to the computer where the management server service (NetIQms) or agent service (NetIQmc) is located. If the service is running, the issue, arrival, and return times are displayed. The basic syntax is: probe mc_hostname NetIQmc probe ms_hostname NetIQms For example, to test the communication between the computer paris and the computer where the AppManager agent is running, use: probe paris NetIQmc Output example: 1029437586 - ctrl 1029437586 - paris <NetIQmc> 1029437586 - ctrl NOTE:Inconsistent arrival times are generally caused by different internal clock settings on the two computers. |
|
profevt |
Displays detailed event collapsing information for all jobs or a specific job on an agent computer. For a summary of event collapsing information, use the jobevt command. The basic syntax is: profevt mc_hostname NetIQmc [ms_hostname job_id] For example, to see detailed event collapsing information for job 6 on the agent computer paris and scheduled by the management server named olympus, use: profevt paris netiqmc olympus 6 Output example: Job [6] =>
KS Name : NT_CpuResource
QDB Site : OLYMPUS1029363296_1029363296
QDB Site UpdTime : 1029363296
MS machine : OLYMPUS <10.5.10.92>
Collapse Intv : 1200 sec
Occur Interval : 1
---------------------------
Event Id : 1029363916_9
Severity : 5
Object list :
Event Message : Number of Processes High
Occurrence Count : 1
CurOccur Count : 0
Collapse Intv : 1200 sec
Total Collapse : 3
Total NonCollap : 1
Current Collapse : 3
First Occurrence : Thu Aug 15 14:49:34 2002
Last Occurrence : Thu Aug 15 14:52:33 2002
---------------------------
Event Id : 1029363916_10
Severity : 5
Object list :
Event Message : Number of Threads High
Occurrence Count : 1
CurOccur Count : 0
Collapse Intv : 1200 sec
Total Collapse : 3
Total NonCollap : 1
Current Collapse : 3
First Occurrence : Thu Aug 15 14:49:34 2002
Last Occurrence : Thu Aug 15 14:52:34 2002 |
|
profile |
Displays detailed information about all jobs or a specific job running on an agent computer. For a summary of job information, use the job command. The basic syntax is: profile mc_hostname NetIQmc [option] The optional parameters specify the type of job for which you want to display information:
For example, to display profile information for all jobs on the agent computer paris, use: profile paris netiqmc Output example: ---------------------- Running-Active Jobs ---------------------- Job [4] => KS Name : NT_CpuLoaded QDB Site : OLYMPUS1029363296_1029363296 QDB Site UpdTime : 1029363296 MS machine : OLYMPUS <10.5.10.92> Thread ID : 2736 (0xab0) Local Action : <> Job Status : worker running Detailed State : <end one iteration> Submit Time : Thu Aug 15 10:27:06 2002 Start Time : Thu Aug 15 10:27:06 2002 StopPending Time : Iteration Intv : 300 sec Iteration Count : 18 Iter Start Time : Thu Aug 15 11:52:07 2002 Iter Stop Time : Thu Aug 15 11:52:08 2002 Iter Run Time : 491 msec Avg Iter Time : 539 msec +++++++ total 1 job |
|
profrsc |
Displays detailed status information about jobs that are currently inactive on an agent computer because of a maintenance period. For a summary of status information for inactive jobs, use the jobrsc command. Each job is associated with a resource ID that identifies the Knowledge Script category for that job. The resource ID is specific to each agent computer. For example, if two SQL Knowledge Scripts are running on an agent computer, both jobs will have the same resource ID. However, that resource ID for SQL Server jobs on that agent computer will not necessarily match the resource ID for SQL Server jobs on other agent computers. The basic syntax is: profrsc mc_hostname netiqmc [ms_hostname job_id] For example, to get detailed information about job number 66, which is running on the agent computer named polar and was scheduled by the management server named olympus, use: profrsc polar netiqmc olympus 66 Output example: Job [66] => KS Name : SQL_DataSpace QDB Site : OLYMPUS904955486_904955487 QDB Site UpdTime : 904955487 MS machine : OLYMPUS <10.1.10.65> Job Status : Inactive RSC ID : 2 # Skipped Iter : 22 Iter Skip Time : Tue Sep 10 14:48:40 2002 |
|
rpstat |
Displays the statistics stored in the local repository of an agent computer. The list includes the number of events, data logs, and messages stored in the local repository. The messages may be waiting for a scheduled upload or they may be stored locally because the agent computer cannot communicate with the management server. Basic syntax: rpstat mc_hostname NetIQccm site|ms ms_hostname
For example, to list statistics for the agent computer named paris, which is managed by the management server named olympus, use: rpstat paris netiqccm ms olympus Output example: ----------------------------------------------
List CCM Site Local RP Stat
----------------------------------------------
QDB Site Name OLYMPUST011029277802_1029277802
QDB Site Updtime 1029277802
MS hostname OLYMPUS <10.5.11.39>
Type #-RP #-Cache LastDur AvgDur
------------- -------- -------- -------- --------
Event 0 0 0 0.00
CtrlEvent 0 4 0 0.00
DataHeader 0 0 0 0.00
DataLog 0 0 0 0.00
Exception 0 0 0 0.00
JobComplete 0 1 0 0.00
|
|
script |
Saves NetIQctrl input and output in a text file. The basic syntax is: script <filename> To stop capturing input and output, use: script done For example: NetIQctrl> script c:\temp\netiqctrl.log
Script <c:\temp\netiqctrl.log> started
NetIQctrl> ping mojo netiqmc
version 2.0.261.5
start_mode Service
start_time Wed Nov 26 15:52:04 1997
trace_level 1
rpc version 2.0
rpc port # 9998
NetIQctrl> script done
Script <c:\temp\netiqctrl.log> done |
|
site |
Displays information about the repository that a specified management server is communicating with. The basic syntax is: site ms_hostname NetIQms For example, to see the repository information for the management server on the computer named paris, use: site paris NetIQms Output example: site name PARIS880588204 site time 880588206 |
|
stat |
Displays statistical information collected by a specific agent computer or management server. The output for this command varies depending on the service and options you specify in the command line. For example, if you run this command to display statistics for the Client Resource Monitor, NetIQmc, the output lists the number of events, data streams, actions, and jobs completed by the agent computer. By default, the statistics reflect the total for the agent computer regardless of which QDB or management server scheduled its jobs. The basic syntax is: stat mc_hostname NetIQmc [option] stat mc_hostname NetIQccm [option] stat ms_hostname NetIQms For NetIQmc, use the following keywords:
For NetIQccm, use the keyword site or ms and a management server hostname to retrieve information associated with a specific AppManager repository or management server. For NetIQms, this command provides detailed statistics covering thread activity and successful and failed communication. For example, to see summary information for the management client named paris, use: stat paris NetIQmc Output example: ----------------------------------------------
List Summary Stat
----------------------------------------------
[Total] :
Type #-Done #-Fail #-Skip
------------ -------- -------- --------
Event 7 0 0
CtrlEvt 8 0 0
DataHeader 2 0 0
DataLog 19 0 0
Exception 0 0 0
JobComplete 7 0 0 |
|
thread |
Displays the status of all threads maintained by a management server. Basic syntax: thread ms_hostname NetIQms [option] Use the optional parameter to select what types of thread information you want to see:
If you don’t specify an option, the command returns information for all management server threads. For example, to get detailed information about the job polling thread maintained by the management server named olympus, use: thread olympus netiqms jobpoll ---------------------------------------------------- Job Poll Thread Info ---------------------------------------------------- ** thread state : sleeping last completed : Thu Aug 15 11:56:35 2002 last start time : Thu Aug 15 11:56:35 2002 current machine : none sleep interval : 5 ** job polling last mod time : Thu Aug 15 11:49:32 2002 run pending jobs : 0 stop pending jobs: 0 ** run pending job submission jobs cached : 0 jobs skipped : 0 jobs submitted : 0 ** stop pending job submission jobs cached : 0 jobs skipped : 0 jobs submitted : 0 |
|
trip |
Sends a path request to the agent computer (NetIQmc) and a management server (NetIQms) to test the round-trip connectivity between them. The basic syntax is: trip mc_hostname NetIQmc ms_hostname For example, to test the round-trip connectivity between the agent computer named shasta and the management server named paris, use: trip shasta NetIQmc paris Output example: 1066766782 - ctrl 1066766831 - mc <shasta> 1066766782 - ms <paris> 1066766831 - mc <shasta> 1066766782 - ctrl NOTE:The response time for each computer is based on its internal clock settings. If the two computers have different clock settings, the UTC timestamps may appear to be incorrect. As long as the round trip is successful, however, you can verify the connectivity between the computers. |
|
uploadsched |
Lists the user-specified upload schedule that has been registered on an agent computer for a specific QDB. The output includes the site identifier for the repository and the separate schedules for uploading events and uploading data. The basic syntax is: uploadsched mc_hostname NetIQmc [ms_hostname] For example, to list the upload schedule that is registered on the agent computer named shasta, use: uploadsched shasta netiqmc Output example: [PARIS1029363296_1029363296] #-EventUpload-# #-DataUpload-# Type: scheduled Recur Type: DAILY Recur Freq: every <1> day(s) Start Time: 13:00:00 End Time: 02:00:00 Interval: 1 hour |
|
unixjob |
Displays a summary of the jobs on UNIX and Linux agent computers. The output includes a list of the job IDs for the selected computer, the management site ID, and the status of each job. The basic syntax is: UnixJob ms_hostname NetIQms [UNIX_agent_IP] Use the optional UNIX_agent_IP parameter to indicate a specific UNIX or Linux computer for which you want to list jobs. To display the job summary for a specific UNIX or Linux computer, include the computer’s IP address in the command line (you must use the IP address and not the hostname). For example: UnixJob rainier netiqms 64.220.132.10 Unix Agent: 64.220.132.10 Job: 26 Unknown Job: 28 Unknown |
|
unixmachine |
Displays configuration and monitoring information for UNIX and Linux agent computers. The output for this command includes:
The basic syntax is: UnixMachine ms_hostname NetIQms [UNIX_agent_IP] Use the optional UNIX_agent_IP parameter to indicate a specific UNIX or Linux computer for which you want to list information. To display information for a specific UNIX or LInux computer, include the computer’s IP address in the command line (you must use the IP address and not the hostname). For example: unixmachine rainier netiqms 64.220.132.10
Unix Agent: 64.220.132.10 (obj id: 149)
Version: 2.0.137.0
Platform OS: SunOS/sparc/5.8
Startup Time: 1028323718
Time Zone Bias: -480+1
Socket Port: 9001
# of Running Jobs: 2
# of Pending Jobs: 0
# of Pending Restart Jobs: 0
Communication Queue Configuration:
CurBrk/MaxBrk/MinBrk/Adj%/MaxSize/IncVal/MaxBlks>
Data 1000/1000/10000/20/65536/10000/20
Event 1000/1000/10000/20/65536/5000/20
JobStat 1000/1000/10000/20/65536/0/20
Exception 1000/1000/10000/20/65536/0/20 |
|
unixmms |
Displays the primary and secondary management servers for a UNIX or Linux agent computer. The output for this command displays the primary and secondary management server hostname for a specified UNIX agent or all UNIX agents. The basic syntax is: UnixMMS ms_hostname NetIQms [UNIX_agent_IP] Use the optional UNIX_agent_IP parameter to indicate a specific UNIX computer for which you want to list information. To display communication details for a specific UNIX computer, include its IP address in the command line (not the UNIX hostname). For example: unixmms rainier netiqms 64.220.132.10 Unix Agent: 64.220.132.10 (obj id: 149) Primary MS: RAINIER Secondary MS: SANDMAN |
|
unixtime |
Displays information about the communication between the management server and UNIX and Linux agent computers. The output for this command includes:
The basic syntax is: UnixTime ms_hostname NetIQms [UNIX_agent_IP] Use the optional UNIX_agent_IP parameter to indicate a specific UNIX computer for which you want to list information. To display communication details for a specific UNIX or Linux computer, include the computer’s IP address in the command line (you must use the IP address and not the hostname). For example: unixtime rainier netiqms 64.220.132.10 Unix Agent: 64.220.132.10 (obj id: 149) Last MSU Heartbeat Received Time: 1028324108 Last Agent Request Reject Time: 0 Last MSU Request Reject Time: 0 Last Agent Data Request Time: 0 Last MSU Data Request Received Time: 0 Last Agent Event Request Time: 1028323797 Last MSU Event Request Received Time: 1028323815 Last Agent Job Status Request Time: 1028323878 Last MSU Job Status Request Received Time: 1028323896 Last Agent Exception Request Time: 1028323722 Last MSU Exception Request Received Time: 0 The UnixTime command is useful for troubleshooting communication or network problems between the management server and UNIX agent. With this command, you can trace the heartbeat and task requests from the UNIX agent and compare them to the requests received by the management server to determine whether there are connection or communication problems. |