Purpose
st_status - Displays the status of all job switch resource table windows upon a node.
Syntax
st_status [-h | -? | -n node_group | node_list]
Flags
Operands
Description
Use this command to report the current status of every window within all job switch resource tables. Status will be reported for reserved windows and non-reserved windows. This command reports whether each window is loaded or unloaded but not whether it is currently in use.
|Issuing the st_status command without any specific node |names will report window status for all of the nodes in the SP system |partition. Nodes listed within the SDR as being off the switch will be |reported as having status of ST_NO_SWITCH.
|If the st_status command is issued with a specific node |name that is not on the switch, the node reports status of |ST_CANT_CONNECT.
Files
Standard Output
The output of this command reports the following data when a window is loaded:
The output of this command reports the following data when a window is in some other state:
The output of this command reports the following data when an error occurs:
Exit Values
Security
You must have appropriate access to the switch table to run this command.
If DCE security checking is being used, you must have the DCE credentials of the switchtbld-status group in order to run this command. If DCE security checking is not being used, you must have root privilege to run this command.
Location
/usr/lpp/ssp/bin/st_status
Related Information
See the chgcss command for information about RESERVED windows.
Commands: ngcreate, ngfind, st_clean_table, st_verify
Examples
To show the status of all windows on k10n15, enter:
st_status k10n15
You should receive output similar to the following:
|***************************************** |Node k10n15 adapter /dev/css0 window 0 returned ST_RESERVED. |Window 0 is RESERVED by VSD. |***************************************** |Status from node: k10n15 User: root |Load request from: k10n15 Pid: 33060 Uid:0 |Job Description: load_client_test |Time of request: Wed_Jun_20_09:15:34_EDT_2001 |Adapter: /dev/css0 Memory Requested: 0 |Window id: 1 |***************************************** |Node k10n15 adapter /dev/css0 window 2 returned ST_SWITCH_NOT_LOADED. |***************************************** |Node k10n15 adapter /dev/css0 window 3 returned ST_SWITCH_NOT_LOADED. |***************************************** |Node k10n15 adapter /dev/css0 window 4 returned ST_SWITCH_NOT_LOADED.
Purpose
st_verify - Verifies that the installation of the Job Switch Resource Table Services component of the SP system completed successfully.
Syntax
st_verify [-h] [-q] [-l logfile]
Flags
Description
Use this command to perform various tests to determine whether the Job Switch Resource Table Services component of the SP system is completely installed. It checks that the necessary commands and files are installed correctly and checks for switchtbld entries in /etc/services and /etc/inetd.conf file. If this is executed on the control workstation and tests are successful, it will also check on each node within that system partition.
You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:
smit SP_verify
and select the Job Switch Resource Table Services Installation option.
Files
|Environment Variables
|PSSP 3.4 provides the ability to run commands using secure remote |command and secure remote copy methods.
|To determine whether you are using either AIX rsh or rcp |or the secure remote command and copy method, the following environment |variables are used. |If no environment variables are set, the defaults are |/bin/rsh and /bin/rcp.
|You must be careful to keep these environment variables consistent. |If setting the variables, all three should be set. The DSH_REMOTE_CMD |and REMOTE_COPY_CMD executables should be kept consistent with the choice of |the remote command method in RCMD_PGM: |
|For example, if you want to run st_verify using a secure remote |method, enter:
|export RCMD_PGM=secrshell |export DSH_REMOTE_CMD=/bin/ssh |export REMOTE_COPY_CMD=/bin/scp
Exit Values
If you do not specify the -q flag, a message is displayed on standard output that indicates whether the tests were successful or not. In either case, the command returns 0 if successful, 1 if not. If errors are detected, more detailed information is recorded in the log file. If you do not specify the -l flag, error messages are recorded in /var/adm/SPlogs/st/st_verify.log.
Security
You must have root privilege to run this command.
Location
/usr/lpp/ssp/bin/st_verify
Related Information
Commands: CSS_test, SDR_test, spmon_ctest, spmon_itest, SYSMAN_test
Examples
To verify the installation of the Job Switch Resource Table Services, saving error messages in st_install.out in the current working directory, enter:
st_verify -l st_install.out
Purpose
startvsd - Makes a virtual shared disk available and activates it.
Syntax
startvsd [-p | -b] {-a | vsd_name ...}
Flags
This option is only used by the Recoverable Virtual Shared Disk subsystem. See the PSSP: Managing Shared Disks.
Operands
Description
The startvsd command makes the specified virtual shared disks available and activates them. It is equivalent to running the preparevsd command followed by the resumevsd command on the specified virtual shared disk.
You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:
smit vsd_mgmt
and select the Start a Virtual Shared Disk option.
Security
You must be in the AIX bin group to run this command.
Restrictions
See PSSP: Managing Shared Disks
Prerequisite Information
PSSP: Managing Shared Disks
Location
/usr/lpp/csd/bin/startvsd
Related Information
Commands: cfgvsd, ctlvsd, lsvsd, preparevsd, resumevsd, stopvsd, suspendvsd, ucfgvsd
Examples
To make available and activate the virtual shared disk vsd1vg1n1, enter:
startvsd vsd1vg1n1
Purpose
statvsd - Displays IBM Virtual Shared Disk device driver statistics of a node.
Syntax
statvsd
Flags
None.
Operands
None.
Description
|The statvsd command displays IBM Virtual Shared Disk |statistics of a node. For example, on a busy server an increasing |number of "requests queued waiting for a buddy buffer" is normal and does not |necessarily imply a problem. Of more value is the "average buddy buffer |wait_queue size" which is the number of requests queued for a buddy buffer |when the statvsd command was issued. See the "Examples" |section for the meaning of output lines.
Prerequisite Information
PSSP: Managing Shared Disks
Related Information
|Commands: ctlvsd, vsdnode
Refer to PSSP: Managing Shared Disks for information on tuning IBM Virtual Shared Disk performance.
|Examples
|The following examples displays IBM Virtual Shared Disk device driver |statistics. |
|VSD driver (vsdd): [KLAPI | IP/SMP] PSSP Version:3 Release:4
|9 vsd parallelism
|61440 vsd max IP message size
|61440 vsd max IP message size
|0 requests queued waiting for a pbuf
|0 requests queued waiting for a cache block
|2689 requests queued waiting for a buddy buffer
|0.0 average buddy buffer wait_queue size
|4 rejected requests
|0 rejected responses
|11 rejected merge timeout
|0 requests rework
|0 64 byte unaligned reads
|0 DMA space shortage
|0 timeouts
|retries: 000000000 | | 0 total retries
|Non-zero Sequence Numbers | |node# expected outgoing outcase? Incarnation:0 | 11 125092 0 | | | 11 Nodes Up with zero sequence numbers: 1 3 5 7 9 11 12 13 14 15 16|
Purpose
stopvsd - Makes a virtual shared disk unavailable.
Syntax
stopvsd {-a | vsd_name ...}
Flags
Operands
Description
The stopvsd command brings the specified virtual shared disks from the suspended state to the stopped state. They become unavailable. All applications that have outstanding requests for the virtual shared disk see these requests terminate with error. Read and write requests return errors with errno set to ENODEV. If the virtual shared disk is in the stopped state, this command leaves it in the stopped state.
You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:
smit vsd_mgmt
and select the Stop a Virtual Shared Disk option.
Security
You must be in the AIX bin group to run this command.
Restrictions
If you have the Recoverable Virtual Shared Disk software installed and operational, do not use this command. The results may be unpredictable.
See PSSP: Managing Shared Disks.
Prerequisite Information
PSSP: Managing Shared Disks
Location
/usr/lpp/csd/bin/stopvsd
Related Information
Commands: cfgvsd, ctlvsd, lsvsd, preparevsd, resumevsd, startvsd, suspendvsd, ucfgvsd
Examples
To bring the virtual shared disk vsd1vg1n1 from the suspended state to the stopped state, enter:
stopvsd vsd1vg1n1
Purpose
supfilesrv - The daemon that serves the file collections on the SP system.
Syntax
Flags
Operands
Description
|This daemon executes on the control workstation and the boot/install |servers. It responds to requests executed on the nodes to update |collections of files configured for file collections. The |supfilesrv daemon is under control of the System Resource Controller |(SRC). It is normally started as part of the SP initialization |scripts. The startsrc -s supfilesrv command invokes the |supfilesrv daemon. The stopsrc -s supfilesrv |command terminates the supfilesrv daemon. The |startsrc command invokes supfilesrv, passing the arguments |as defined by the SRC. The supfilesrv daemon is invoked |as:
|supfilesrv -p /var/sysman/sup/supfilesrv.pid
The supfilesrv daemon ignores SIGINT, SIGHUP and SIGPIPE.
In case of errors, the server may terminate, the clients will not be able to connect to the server, and the changes in the collections may not be reflected at the client. In case of error conditions, the server prints error messages to standard error and may possibly terminate.
No security information is directly modified in the server.
Files
The PID of the supfilesrv process is written into the PID file passed as a command line argument.
Standard Output
The command initially prints the startup message with the protocol version.
Standard Error
The command prints all error messages to standard error.
Exit Values
Security
You must have root privilege to run this command.
Restrictions
This command should be invoked only from the file collection server hosts.
Implementation Specifics
This command is part of the IBM Parallel System Support Programs (PSSP) Licensed Program (LP).
Prerequisite Information
PSSP: Administration Guide
Location
/usr/lpp/ssp/bin/supfilesrv
Related Information
Commands: supper
Examples
startsrc -s supfilesrv
stopsrc -s supfilesrv
Purpose
Manages the SP file collections.
Syntax
supper [-d ] [-v] subcommands
Flags
Operands
Subcommands:
Description
This command is a Perl script that provides various file collection management capabilities. The supper update subcommand invokes the sup client program to upgrade file collections from the file collection server. The supper scan subcommand is used at the file collection server to create the scan file /var/sysman/sup/<filecollection/scan.
This file contains the last modification time of the files in the collection and used for efficient file collection transactions. If this file is present, it is important to either delete this file or rerun the scan subcommand when files in the collection are modified. However, if this file is not present (which is the default), it is not necessary to create this file using supper scan subcommand when new files are created in the file collection or when existing files are modified.
The supper command identifies the boot/install server of the node as the file collection server. This is typically invoked from crontab to periodically update the file collections from the server. You can invoke supper as an interactive session by entering the command without any parameters or subcommands. This allows you to enter the subcommands in an interactive dialog.
The supper command captures SIGINT, SIGQUIT, and SIGALRM and ignores these signals. However, if the sup or supscan child process is active, on receiving SIGINT, supper sends SIGKILL signal to the child process.
When an update is in progress, if supper receives SIGINT, it stops the sup child process. If the updates are not done properly, either no files or only some files in the collection may be updated at the client. It will have different effects depending on what file collection is being updated. The log files generated can be used to trace the errors.
Files
Standard Input
When invoked without any parameters, provides interactive shell which accepts all the subcommands listed above.
Standard Output
When invoked without any command line arguments, the command provides an interactive shell displaying the prompt. The results are displayed to standard output in response to the subcommands typed at the prompt. When invoked with the -v option, messages output by the sup client program are displayed. The -d option prints debugging information.
Exit Values
Security
You must have root privilege to run this command.
If the user.admin file collection is used for user management, the change in the user management files in the server will be reflected at the client after the supper update.
Restrictions
There is no file collection server for SP control workstation, so the supper update subcommand is not applicable to control workstation.
Implementation Specifics
This command is part of the IBM Parallel System Support Programs (PSSP) Licensed Program (LP).
Prerequisite Information
PSSP: Administration Guide
Location
/var/sysman/supper
Related Information
Commands: sup, supfilesrv
Examples
/var/sysman/supper rlog /var/sysman/supper status /var/sysman/supper scan user.admin /var/sysman/supper update power_system
Purpose
suspendvsd - Deactivates an available virtual shared disk.
Syntax
suspendvsd {-a | vsd_name...}
Flags
Operands
Description
The suspendvsd command brings the specified virtual shared disks from the active state to the suspended state. They remain available. Read and write requests which were active while the virtual shared disk was active are suspended and held. Subsequent read and write operations are also held. If the virtual shared disk is in the suspended state, this command leaves it in the suspended state.
If you issue this command for the server node and not the client, retries occur unsuccessfully. An error occurs within 15 minutes.
You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:
smit vsd_mgmt
and select the Suspend a Virtual Shared Disk option.
Security
You must be in the AIX bin group to run this command.
Restrictions
If you have the Recoverable Virtual Shared Disk software installed and operational, do not use this command. The results may be unpredictable.
See PSSP: Managing Shared Disks.
Prerequisite Information
PSSP: Managing Shared Disks
Location
/usr/lpp/csd/bin/suspendvsd
Related Information
Commands: cfgvsd, ctlvsd, lsvsd, preparevsd, resumevsd, startvsd, stopvsd, ucfgvsd
Examples
To bring the virtual shared disk vsd1vg1n1 from the active state to the suspended state, enter:
suspendvsd vsd1vg1n1
Purpose
switch_stress - Tests the function of a specific switch chip.
| Attention |
|---|
|
ATTENTION - READ THIS FIRST: Do not activate the switch advanced diagnostic facility until you have read this section completely, and understand this material. If you are not certain how to properly use this facility, or if you are not under the guidance of IBM Service, do not activate this facility. Activating this facility may result in degraded performance of your system. Activating this facility may also result in longer response times, higher processor loads, and the consumption of system disk resources. Activating this facility may also obscure or modify the symptoms of timing-related problems. |
Syntax
Flags
Operands
None.
Description
This command starts the switch chip stress test, which determines whether the specified switch chip is malfunctioning under stress. You are required to specify the switch chip ID that appeared in the primary node error reports.
The model argument lets you select a single test model. By default, all models will be executed.
You can specify the nodes that are allowed to participate in the test, or nodes that are not allowed to participate in the test. If the same node is present in both lists, it is not allowed to participate in the test. You must be aware that the selected nodes will not be able to run any application that uses a switch network during the test execution. By default all nodes are allowed to participate in the test. These nodes could be specified as a list of nodes or as a file that contains the list. The data_size argument allows you to control the amount of data that will be sent by every sender on every test iteration. By default this value is set to 360MB.
You can provide a path to a file that contains the data pattern to be used during the test. By default the output of the test is displayed on the command line. You can request to display the output on the SPD GUI.
|Security
|When restricted root access (RRA) is enabled, this command can only be run |from the control workstation.
Location
/usr/lpp/ssp/bin/spd/switch_stress
Examples
switch_stress -s 16
switch_stress -s 20 -g
switch_stress -s 25 -a n05 n06 n11
switch_stress -s 25 -f 2,9
switch_stress -s 25 -m ModelA
switch_stress -s 25 -z 1000
switch_stress -s 25 -p /tmp/spd/pattern1.dat
|switch_stress -n 1
Purpose
sysctl - The command interface to the Sysctl remote command execution server
Syntax
Flags
Operands
Description
The sysctl program provides a simple command line interface for communicating with the Sysctl server, sysctld. Together the Sysctl client and server provide remote execution capability needed to manage the SP system from a single point of control. The client connects to servers using TCP/IP, passes options and procedures to the server, and writes output that the server returns to standard output. The client does not interpret (as a shell) the procedures it passes.
The Sysctl server uses the Tcl imbeddable command language as the foundation for its built in interpreter. The server is augmented with application specific procedures. You may tailor the Sysctl configuration to make different procedures available on different servers. The Sysctl (Tcl) expressions that are passed to the servers for execution can be anything from a single procedure invocation to an entire script. A simple Tcl wrapper can be used to invoke executables on the server that are C language programs, Perl programs, or shell scripts.
The server uses SP authentication services for reliable third party authentication. Sysctl requests from the client to servers contain authentication information using DCE or Kerberos Version 4 credentials, depending on the trusted services authentication method chosen when the system was configured. The authentication information reliably identifies the user that initiated the request. No authentication information is passed when the -n or -x option is specified, when the system administrator has not configured either trusted services authentication method, or when the user does not have credentials. Permission to access the resources of the servers is granted based on the identification of the client as an unauthenticated or authenticated user, in conjunction with authorization mechanisms on the server that implement local access control policies. A description of those mechanisms can be found in the sysctld daemon and in the "Controlling remote execution by using Sysctl" chapter in PSSP: Administration Guide.
Environment Variables
The LC_ALL locale settings are passed to the Sysctl server to be used, if possible, when running the command. When "Compatibility" authentication is being used on the client host (where this command is invoked), the KRBTKFILE environment variable, if set, is assumed to name a Kerberos Version 4 ticket cache file owned by the user issuing the command.
Files
This command reads all cluster files specified by the -c option, and a replay file if specified by the -r option.
Standard Input
This command only reads standard input when it is specified as the source of a replay file or a cluster file. See the descriptions of the -r and -c flags.
Standard Output
All output produced by this command is copied directly from the server.
Standard Error
Output consists of error messages from this command plus error messages produced by the servers and text returned as Tcl errors by Sysctl procedures. When this command directs requests to servers running version 1.1 of Sysctl (included in PSSP releases prior to 3.1), error messages returned by those servers may differ from those produced by Sysctl version 2.1 servers. This command will report some errors and continue to complete the request. These errors result from entry of values that are not valid for some command options, where default values were applied.
Exit Values
Security
Use of the Sysctl built in procedures for ACL management may alter the authorization characteristics of the affected objects on the targeted servers. Such changes take effect immediately.
Implementation Specifics
This command is part of the IBM Parallel System Support Programs (PSSP) Licensed Program (LP) (file set ssp.clients).
Prerequisite Information
The chapters on security and Sysctl in PSSP: Administration Guide.
Location
/usr/lpp/ssp/bin/sysctl
Related Information
Commands: dshbak, hostlist, sysctld
Examples
These examples show procedures invoked from the shell prompt. Unless noted otherwise, the syntax is the same (minus the word sysctl) when invoking the procedure from within an interactive Sysctl session.
sysctl -h ceti-alpha5 listfs
sysctl -h ceti-alpha5 acladd -p arielle
The server returns the full entry that it inserted into the ACL file, for example:
_PRINCIPAL arielle.@ABC.COM
sysctl aclcheck -f /etc/sysctl.pman.acl frank
The server returns 1 if frank is granted access, 0 if not.
sysctl -h ceti-alpha5 checkauth -cmd test:mount_if
Purpose
sysctld - The Sysctl remote command execution server.
Syntax
sysctld [-ds] [-a acl] [-f file] [-k keyfile] [-l logfile] [-P port]
Flags
On a host which has DCE authentication configured, acl is appended to the CDS name of the Sysctl service's RPC entry to form the full object name with which the ACL is associated. The full object name used to refer to ACL /etc/sysctl.acl when using the dcecp command to manage its entries on host xyz.abc.com has the form /.:/subsys/ssp/host1/sysctl/host1/etc/sysctl.acl.
On a host which does not have DCE configured or which also has Kerberos Version 4 configured, acl is the fully qualified pathname of the Sysctl ACL file used to specify access controls. If acl is not a valid pathname or the file does not exist, the default value is used. No verification of the content of the file takes place until an ACL check is attempted to authorize a user.
Operands
None.
Description
The sysctld daemon is the server component of the Sysctl remote command execution facility. Security and performance characteristics of sysctld make it an ideal mechanism for managing a large, distributed computing environment. An instance of sysctld runs on every SP node and the control workstation. Procedures are sent to the sysctld daemon by the sysctl client program. The client and server use a PSSP authentication mechanism that both have configured to validate the identity of the user. If the user is authenticated, the credentials obtained by that process are used to check the authorization of the user to use the requested Sysctl resources. Sysctl servers can also be configured to support requests by unauthenticated clients.
Security and Access Control
When a request is received, sysctld establishes the client's identity using the authentication protocol information passed by the client. If the information contains valid DCE credentials and DCE authentication was configured on the local system, the requestor is authenticated as a DCE principal. If the information contains valid Kerberos Version 4 credentials and "Compatibility" authentication was configured on the local system, the requestor is authenticated as a Kerberos Version 4 principal. If the request contains no credentials or credentials that are not valid, the client is identified as an unauthenticated user.
Determining Connection Authorization Policy
Whenever a client connects to a server, the svcconnect Sysctl procedure is invoked. If the user is not authorized to run this procedure or if the procedure returns a Tcl error, the result of the procedure is returned to the user and the connection is broken. Therefore, svcconnect determines the connection policy for the server. The default svcconnect access control policy is to allow connection by any authenticated client on hosts that support authentication, and to allow connection by any client on systems that do not. This policy can be altered in the Sysctl configuration file by redefining the svcconnect procedure itself via the create proc or rename Sysctl procedures, or by changing its authorization callback using the setauth procedure.
Access Control using Authorization Callbacks
Once a client connection is blessed by the svcconnect callback, access to Sysctl procedures and variables is determined dynamically by the execution of authorization callbacks that are assigned at configuration time to each procedure and variable. In a typical command language, a procedure has a name, a set of arguments, a set of procedures which form the body of the procedure, and a return value. With Sysctl procedures, an additional attribute is added; a policy for determining who is able to run the procedure. These policies are implemented using callbacks that are pieces of Tcl code logically attached to all procedures and variables when they are defined to the Tcl interpreter during server initialization. Each authorization callback returns either a normal Tcl result, allowing access to the resource, or a Tcl error, preventing access. The text "Authorization Denied" is returned to the client as the Tcl result.
A procedure's callback is executed just prior to execution of the body of the procedure to which it is attached. If it returns a normal result, the procedure is executed.
For Sysctl variables, the callback is executed prior to resolving a reference to a read-only variable. Access is allowed if a normal result is returned. It is possible to create a "private" variable whose value is available to only a certain set of clients.
The sysctld server has a set of predefined procedures designed to be used as authorization callbacks. These procedures provide a simple authorization policy. If a more complex authorization policy is required, you may write your own authorization callback procedures. These procedures are:
Bypassing Authorization Callbacks
Under certain circumstances, the authorization callbacks are bypassed by the server. At these times, all procedures and variables are accessible. This occurs when:
Since authorization checks are bypassed during procedure execution, users are able to execute procedures that contain procedures that they are not authorized to run directly. If, for example, a variable has the SYSTEM callback attached to it, a procedure for which a user is authorized can reference or modify the variable, even though the user cannot use it directly.
Authorization Variables
Several variables are set by the server prior to executing the client request. These variables provide a mechanism for external procedures to perform their own authorization checking independent of the server's standard authorization checks. They cannot be changed using the Tcl set command (are read-only). They are:
Server Configuration
At server initialization, the sysctld daemon reads a configuration file. By default this file is named /etc/sysctl.conf. The server interprets the contents of the file as Tcl procedures. Typically, additional procedures and variables are defined in this file. Also, procedures are available that instruct the server to process additional configuration files or dynamically load shared libraries. In this way the set of procedures available to a sysctld server is extensible. Refer to the information on the sysctl_conf file for more details.
Starting, stopping, and querying the sysctld daemon
The sysctld daemon is under System Resource Controller (SRC) control. It uses the signal method of communication in SRC. The sysctld daemon is a separate subsystem, named sysctld, not associated with any SRC group. It is started using the startsrc command, normally automatically by init, as set up during PSSP installation. It starts the daemon with default arguments and SRC options. It is set up to respawn on termination, and there is only one instance of sysctld on a particular node or control workstation. Do not start the sysctld daemon, except by using the startsrc command.
To stop the sysctld daemon, use the stopsrc command. It stops the daemon, without allowing it to respawn.
To display the status of the sysctld daemon, use the lssrc command.
To override the daemon's default arguments, specify the -a flag on the startsrc command. To change them permanently or to change other subsystem attributes, use the chssys command. Refer to AIX Commands Reference and AIX General Programming Concepts: Writing and Debugging Programs for more information about daemons under SRC control and how to modify their arguments. To view the current SRC options and daemon arguments, use the odmget command.
Environment Variables
Though the server is started in the default locale for the system it runs on, it will use the client's locale information (only available for clients running Sysctl version 3.1 or higher) in the child process that runs the client command. If the client's locale is not available on the local system, the server will use the default locale, except when the client request includes the flag that disallows that option.
Files
Standard Error
Standard error is used only when the daemon fails to start, prior to opening the log file.
Exit Values
Security
You must have root privilege to run this command.
Implementation Specifics
This command is part of the IBM Parallel System Support Programs (PSSP) Licensed Program (LP) (file set ssp.sysctl).
Prerequisite Information
The chapters on security and Sysctl in PSSP: Administration Guide.
Location
/usr/lpp/ssp/bin/sysctld
Related Information
Commands: sysctl
Files: sysctl_acl, sysctl_conf
Examples
startsrc -s sysctld
stopsrc -s sysctld
lssrc -s sysctld
odmget -q subsysname=sysctld SRCsubsys
Purpose
SYSMAN_test - Verifies that the installation and customization of the Systems Management components of the SP system completed successfully.
Syntax
SYSMAN_test [-q | -v] [-l log_file]
Flags
Operands
None.
Description
The SYSMAN_test command performs various tests to determine whether the systems management components of the SP system are completely installed and customized properly.
A return code of 0 indicates that the test completed as expected; otherwise it returns the number of errors. If you do not specify the -q flag, a message is displayed on standard output that indicates whether the tests were successful or not. In either case, the command returns 0 if successful, 1 if unsuccessful. If errors are detected, more detailed information is recorded in the log file. If you do not specify the -l flag, error messages are recorded in /var/adm/SPlogs/SYSMAN_test.log.
You can use the System Management Interface Tool (SMIT) to run this command. To use SMIT, enter:
smit SP_verify
and select the RS/6000 SP System Management option.
Files
|Environment Variables
|PSSP 3.4 provides the ability to run commands using secure remote |command and secure remote copy methods.
|To determine whether you are using either AIX rsh or rcp |or the secure remote command and copy method, the following environment |variables are used. |If no environment variables are set, the defaults are |/bin/rsh and /bin/rcp.
|You must be careful to keep these environment variables consistent. |If setting the variables, all three should be set. The DSH_REMOTE_CMD |and REMOTE_COPY_CMD executables should be kept consistent with the choice of |the remote command method in RCMD_PGM: |
|For example, if you want to run SYSMAN_test using a secure remote |method, enter:
|export RCMD_PGM=secrshell |export DSH_REMOTE_CMD=/bin/ssh |export REMOTE_COPY_CMD=/bin/scp
|The HN_METHOD=reliable environment variable can be used to run |SYSMAN_test using the reliable_hostname instead of the |default initial_hostname. For example:
|export HN_METHOD=reliable |SYSMAN_test -l sm.errors
Related Information
Commands: CSS_test, jm_install_verify, jm_verify, SDR_test , spmon_ctest, spmon_itest
Location
/usr/lpp/ssp/bin/SYSMAN_test
Examples
To verify systems management following customization, saving error messages in sm.errors in the current working directory, enter:
SYSMAN_test -l sm.errors
Purpose
syspar_ctrl - Starts, stops, adds, deletes, and refreshes the system partition-sensitive subsystems installed on your SP system.
Syntax
Flags
Operands
syspar_ctrl option haem
Description
This command acts as an interface to the system partition-sensitive subsystems supporting the functions that are shared by all subsystems. This command is also referred to as the Syspar Controller. It can be used to add or delete, start or stop, refresh or restore the subsystems, and various other functions. When used on the control workstation, it works with the subsystems on the control workstation. When used on the nodes, it works with the subsystems on the nodes. The refresh option is an exception. To refresh some subsystems, the subsystem must be refreshed on both the control workstation and on the nodes. In this case, the refresh on the control workstation will dsh an appropriate refresh command from the control workstation to the appropriate nodes.
This command supports two types of options: primitive options and macro options. Primitive options are passed directly to the underlying control scripts, for example, -a (add), -d (delete), -r (refresh). Macro options conveniently group a commonly used set of primitive options into one option, for example, -R (restore). All of the subsystems and each subsystem's control script that are managed by the Syspar Controller are listed in the Syspar Controller subsystems file. By default, all of the control scripts listed in the Syspar Controller subsystems file will be called unless a subsystem_name is provided. In that case, the control script for just the specified subsystem will be called.
This command is automatically called when the system is partitioned (spapply_config) to first stop and delete the system partition-sensitive subsystems from system partitions that are being removed, and then to add and start the system partition-sensitive subsystems (for example, hats, hb, and hr) in new system partitions.
The Syspar Controller is also called when restoring the SDR with sprestore_config to first clean up and then add and start the system partition-sensitive subsystems (for example, hats, hb and hr) in each system partition.
The Syspar Controller also needs to be called with refresh flag (-r) by the System Administrator using the command line whenever a node is added or deleted from the system, or a node is migrated to a new level of PSSP.
Files
Security
You must have root privilege to run this command.
Environment Variables
Exit Values
Implementation Specifics
This command is part of the IBM Parallel System Support Programs (PSSP) Licensed Program (LP).
Location
/usr/lpp/ssp/bin/syspar_ctrl
Related Information
Commands: emonctrl, hatsctrl, hbctrl, hrctrl, haemctrl, hagsctrl, pmanctrl, sp_configdctrl, spapply_config, spcw_apps, sprestore_config
Examples
syspar_ctrl -G -A
syspar_ctrl -G -D
syspar_ctrl -r
syspar_ctrl -R
syspar_ctrl -k
syspar_ctrl -h haem
syspar_ctrl -E
lssrc -a | grep spp1 lssrc -a | grep sp_configd