This chapter describes software considerations for oVTCS, the version of VTCS that runs on the VSM console server.
oVTCS represents StorageTek Virtual Tape Control Software (VTCS) Release 7.3, customized to operate on the VSM console in the Solaris operating environment. oVTCS performs the following functions:
Influences the allocation of Virtual Tape Drives (VTDs).
Virtual Tape Storage Subsystem (VTSS) is the VSM disk buffer containing virtual volumes (VTVs) and transports. The VTSS is disk device with microcode that enables emulation of 32 or 64 transports. The device can read and write "tape" data from/to disk, and can read and write the data from/to an RTD.
A Virtual Tape Drive (VTD) is a transport in VSM's Virtual Tape Storage Subsystem (VTSS) that emulates a physical tape cartridge. The data written to a VTD is actually written to disk. The VTSS has 256 VTDs that perform virtual mounts of VTVs.
Manages the use of Virtual Tape Volumes (VTVs), including migration and recall.
Migration is the movement of data from the VTSS to the Real Tape Drive (RTD) where VTVs are stacked onto MVCs.
Recall is the movement of VTVs back to the VTSS from the MVC. VSM provides the ability to recall VTVs on demand.
Manages the use of real tape media and transports used by VSM.
This section describes the oVTCS policy parameter file and how to activate this file in your VSM console configuration.
In a VSM console configuration, oVTCS utilizes an oVTCS policy parameter file to include management and storage class policies for the oVTCS configuration. During startup, oVTCS examines the status of VTVs in the CDS, loads the defined policies, and implements the required actions in order to honor the policies.
When oVTCS is running in a cluster, this parameter file is automatically distributed to each node. The file settings are also persistent across restarts.
The method used to initially load this parameter file is dependent on your configuration.
See "Loading the oVTCS Policy Parameter File Using the SMCUUUI Utility".
See "Loading the oVTCS Policy Parameter File Using the VSM GUI".
The oVTCS policy parameter file must include at least one instance of each of the following statements:
Note:
With the exception ofTAPEPLEX
, the following statements closely match the ELS usage. Refer to your Oracle StorageTek ELS publications for more information about these statements.These statements describe scratch and MVC pools for the instance of oVTCS.
Note:
In shared CDS mode,POOLPARM
statements in the CDS are not used.These statements define the attributes of the various volser ranges and allocates them to POOLPARM
statements. These closely match the ELS usage of this statement, different only in that changing the VOLPARM
statements does not update the oVTCS configuration.
These statements define the storage classes. A storage class is a named list of storage attributes that identify performance goals and availability requirements for a data set.
These statements define the management classes. A management class is a collection of management attributes, assigned by the storage administrator, that are used to control the allocation and use of space by a data set.
These statements define the network contact details for other instances of ACSLS, HSC, and VLE. If VSM console has RTDs to migrate to, then a TAPEPLEX
statement is required regardless of the type of TAPEPLEX (ACSLS, HSC, or VLE).
If there are multiple systems that VSM console can migrate to, then a separate TAPEPLEX
statement for each system is required.
The format of the TAPEPLEX
statement is as follows:
TAPEPLEX NAME=
tapeplex_name
SERVer(
server
[,
server
] [,
server
] [,
server
])
[SUBSYS=
subsystem_name
]
where:
NAME
specifies the name assigned to the TapePlex. This can be an ACSLS, HSC, or VLE system, and must match the TapePlex name assigned by the target ACSLS, HSC, or VLE.
SERVer
specifies one or more server paths to the named TapePlex. You can specify a host name or IP address.
SUBSYS
specifies the name of the HSC MVS subsystem and is required only when the target TapePlex is an HSC, and only when there are multiple HSC subsystems on the same MVS host.
The following is an example of a TAPEPLEX
statement for an HSC system, with the SERVer
parameter specifying the host name:
TAPEPLEX NAME=HSCVTCS SERV(
host-name
)
Alternatively, the SERVer
parameter can specify the IP address in place of host-name
:
The following is an example of a TAPEPLEX
statement for a multi-node VLE system, with the SERVer
parameter specifying the IP address of each node:
TAPEPLEX NAME=VLE1 SERV(
ip_address1
,
ip_address2
,
ip_address3
)
In this type of configuration, you may want to perform maintenance on an individual VLE node. The SMC SERVer DISable
command is not supported by VSM console. Instead, you must use the following process:
In the oVTCS policy parameter file, update the TAPEPLEX
statement to remove the P address of the node requiring maintenance.
Issue the oVTCS MGMTDEF ACTIVATE
command with the updated parameter file.
Perform maintenance on the node that was removed.
Update the TAPEPLEX
statement to re-add the node IP address.
Issue the oVTCS MGMTDEF ACTIVATE
command to load the updated parameter file.
The oVTCS parameter file can optionally include the following statements:
Note:
The following statements closely match the ELS usage. Refer to your Oracle StorageTek ELS publications for more information about these statements.This statement specifies an identifying string (name) for the file.
These statements specify migration request settings for managing migrates to storage classes from VTSSs.
These statements specify migration request settings for individual VTV copies processed by immediate migration.
These statements assign a swap-to RTD device type to an MVC media name. When an error occurs while reading an MVC on an RTD, VTCS may swap the MVC to another RTD to retry the operation.
These statements specify lists of storage classes and their corresponding preferencing.
These statements specify storage class usage rules that apply to the Storage Class list and its preferencing specified on a referenced STORLST
control statement.
These statements specify a list of VTSSs and their corresponding preferencing.
These statements specify storage class usage rules that apply to the VTSS list and its preferencing specified on a referenced VTSSLST
control statement.
These statements define commands to be executed at startup, or whenever the parameter file is loaded. It provides an equivalent of the ELS startup command file.
To activate the oVTCS policy parameter file in a mainframe configuration, use the SMC SMCUUUI
utility to issue the oVTCS MGMTDEF
command.
The oVTCS MGMTDEF
command activates the oVTCS policy parameter file.
From the SMCUUUI
utility, specify the name of your oVTCS parameter file, along with the MGMTDEF
command statement with the ACTIVATE
parameter, in a UUIIN SDD
statement, as shown in Example 5-1.
The oVTCS parameter file can exist anywhere as long as the fully qualified path and file name is specified.
Refer to the ELS Command, Control Statement, and Utility Reference for information about the SMCUUUI
utility.
Note:
The oVTCSMGMTDEF
command is a native oVTCS command, and is not related to the SMC MGMTDEF
command.As shown in Figure 5-1, the oVTCS MGMTDEF
command includes the following parameters:
optionally, validate the parameters contained in the specified oVTCS parameter file and then activate these parameter settings.
Note:
If you do not specify theACTIVATE
parameter, the parameters contained in the specified oVTCS parameter file are only validated.optionally, list the parameters that are read from the oVTCS parameter file.
To activate the oVTCS policy parameter file using the VSM GUI supplied with the VSM console:
Start the VSM GUI application.
Access the VSM Console menu. This menu includes the following options:
Command Line Interface (CLI)
Configuration/Policy
Console Log
Select the VSMc Configuration/Policy tab. This page enables you to download, edit, and upload an oVTCS Policy file that defines oVTCS policy settings.
Select the tapeplex name from the menu.
Select the server address from the menu. Only server addresses configured for the selected tapeplex are listed.
Click the Download button to specify your policy parameter file and load it into the VSM GUI.
Click the Edit button to make any desired edits to the file.
Click the Upload button to activate the file in the specified oVTCS tapeplex.
Refer to the VSM GUI User's Guide for more detailed information about using the VSM Console Menu to load your configuration settings.
The following list describes oVTCS command considerations:
CDS Logging is not supported. Therefore, the LOGPOL
parameter is not valid in the CONFIg GLOBAL
statement.
If you use SMC 7.3, XAPI security must be disabled by setting the XSECurity
parameter of the SMC HTTP
command to OFF
. This enables RTDs attached to HSC to come online.
Refer to the ELS Command, Control Statement, and Utility Reference for information about the SMC HTTP
command.
oVTCS includes a native MGMTDEF
command that enables you to activate the oVTCS policy parameter file in a mainframe configuration. This command is not related to the ELS MGMTDEF
command. See "Loading the oVTCS Policy Parameter File Using the SMCUUUI Utility" for more information.
You must use CONFIg VTVVOL
and CONFIg MVCVOL
statements to add VTVs or MVCs to the CDS. You cannot use the POOLPARM
or VOLPARM
method.
You can use POOLPARM
and VOLPARM
for SUBPOOL
naming, however, you must use CONFIg VTVVOL
and CONFIg MVCVOL
to define the volumes.
Refer to the ELS Command, Control Statement, and Utility Reference for information about the POOLPARM
and VOLPARM
control statements.
Refer to the ELS Legacy Interfaces Reference for more information about CONFIg VTVVOL
and CONFIg MVCVOL
control statements.
When issuing mounts from the SMCUUUI
utility, use the following conventions:
You must specify the full MOUNT
keyword. Unlike the ELS command, you cannot abbreviate this keyword.
Specify the device address as N
, NAME
, or DRIVE_NAME=
devaddr
, where devaddr
is the device address.
Specify the volser as V
, VOL
, or VOLSER=
volser
, where volser
is the volume serial number or SCRTCH
.
Specify the subpool as P
, POOL
, SUBPOOL
, or SUBPOOL_NAME=
subpool-name
.
When issuing dismounts from the SMCUUUI
utility, use the following conventions:
You can specify the full DISMOUNT
keyword or the abbreviated DISM
.
Specify the device address as N
, NAME
, or DRIVE_NAME=
devaddr
, where devaddr
is the device address.
Specify the volser as V
, VOL
, or VOLSER=
volser
, where volser
is the volume serial number or SCRTCH
.
Handling of tape libraries in a non-shared CDS mode:
If your configuration does not run in shared CDS mode, the following parameter restrictions apply:
RTD
statements in the oVTCS configuration must include STORMNGR
parameters.
In VTSS
statements in the oVTCS configuration, the DEFLTACS
parameter can only be defaulted.
In STORCLAS
statements, use of the ACS
parameter requires the STORMNGR
parameter.
In MGMTCLAS
statements, the ACSLIST
parameter cannot be used.
If your configuration runs in shared CDS mode, all libraries are considered 'remote' and are therefore part of an independent TapePlex. The name of the TapePlex that is the default library is supplied as part of the database configuration. Normally, this TapePlex would also supply the CDS. Therefore, the restrictions described above do not apply.
The oVTCS TRace
command includes only two options, ON
and OFF
.
TRace ON
closes all trace files and opens a new trace file for all running processes. This is the recommended setting.
TRace OFF
stops all tracing.
Unlike the ELS TRace
command, you cannot specify specific components to be traced.
Use the SMC VMSG
command to obtain VSM console messages
See "Starting/Stopping the VSM console Message Processor" for more information about this command.
Use the HSC DBSERVER
command to enable the VSM console to share an HSC CDS.
See "Running the oVTCS CDS Database Server" for more information about this command.
Use the SMC SMCUSMF
utility to off-load SMF-type records from a VSM console server.
See "Off-loading VSM console SMF Records" for more information about this utility.
Use the internal MVS GETMGPOL
command to return listings of active oVTCS policy statements:
Specify the GETMGPOL
command with no subparameters to return oVTCS MGMTCLAS
and STORCLAS
statements.
Specify GETMGPOL MGMTCLAS
to return oVTCS MGMTCLAS
statements.
Specify GETMGPOL STORCLAS
to return oVTCS STORCLAS
statements.
Specify GETMPOL FLATDD(
filename)
to return all oVTCS policy statements. This returns the entire contents of the oVTCS parameter file.
oVTCS includes a set of operator and administrator commands. These commands are identical to their ELS VTCS counterpart, with few exceptions as described in "oVTCS Command Considerations".
Use one of the following methods to issue these commands:
Use the SMC Route command or SMCUUUI
utility to send commands from an SMC client to oVTCS on the VSM c.onsole.
Refer to the ELS Command, Control Statement, and Utility Reference for information about the SMC Route
command and SMCUUUI
utility.
Start the VSM GUI application supplied with the VSM console and use the VSMc Command Line Interface (CLI) feature to send commands to oVTCS on the VSM console. Refer to the VSM GUI User's Guide for information about using this feature.
Start the VSM GUI application.
Access the VSM Console menu.
Select the VSMc Command Line Interface (CLI) tab. This page enables you to download, edit, and upload an oVTCS Policy file that defines oVTCS policy settings.
Select the tapeplex and the appropriate node server address.
Enter the oVTCS command in the input text box and click Submit.
The command is recorded in the Command Log and command Output tables.
oVTCS includes the commands listed below. Refer to the ELS Command, Control Statement, and Utility Reference for information about each command.
ARCHive
AUDIT
CANcel
CONSolid
CONFIg
DEComp
DELETSCR
DISMount
Display
CMD
MSG
SERVer
ACTive
CLInk
CLUster
CONFIG
LOCKs
MIGrate
MVC
MVCPool
PATH
Queue
REPlicat
RTD
SCRatch
STORclas
STORMNgr
TASKs
VSCRatch
VTD
VTSS
VTV
DRMONitr
EEXPORT
EXPORT
INVENTRY
MEDVERfy
MERGMFST
METADATA
MIGrate
Mount
MVCDRain
MVCMAINT
MVCPLRPT
MVCRPt
RECall
RECLaim
RECONcil
SCRPT
SET MIGOPT
TRace
Vary
(CLInk
, PATH
, RTD
, VTSS
)
VLEMAINT
VTVMAINT
VTVRPt
The VSM console includes several XAPI server operator and administrator commands that enable you to manage the XAPI server component that operates within the VSM console.
Use one of the following methods to issue these commands:
Issuing XAPI Server Commands Using the xapi_startup_file
The xapi_start_file
is a file of XAPI server commands that is read during XAPI server startup.
This is the preferred method of specifying XCLIENT
and XUDB
definitions and XSECURITY
and MSGLVL
specifications.
As this file is read at startup, there is no need to re-enter these commands if the XAPI server component is restarted.
The default path for the xapi_start_file under VSM console is: /data/ovtcs/config/xapi_startup_file
.
Issuing XAPI Server Commands Using the oVTCS_cli XCMD interface
The oVTCS_cli
interface may be used to direct commands to the XAPI server component by specifying 'XCMD
' followed by the XAPI server command string.
For example, to enter the XAPI server 'LOG 0011
' command using the oVTCS_cli
enter the command:
oVTCS_cli ' XCMD LOG 0011'
This is the preferred method to enter XAPI server LIST
and TRACE
commands when directed by StorageTek Software support.
Issuing XAPI Server Commands Using the VSM GUI
You can issue XAPI server commands to the VSM console using the VSM GUI VSM console command line interface option.
Refer to the VSM GUI User's Guide for information about using the VSM console menu options.
The XCMD LIst
command displays XAPI server component and environment settings. The XCMD LIst
command is intended to be used primarily as directed by StorageTek Software Support.
As shown in figure, the XCMD LIst
command includes the following parameters:
optionally, displays all XAPI server parameters and environment variables. ALl
is the default when no parameters are specified on the LIst
command.
optionally, lists the named (NNNN
) XAPI server control block in character hexadecimal. The name (NNNN
) or name-index (NNNN-IIII
) combinations are:
HTTPCVT
indicates the main XAPI server shared segment.
HTTPGBL
indicates XAPI server global definitions.
HTTPREQ-
nnn
indicates the XAPI server request block.
HTTPAPI-
nnn
indicates the XAPI server API
request block.
XCLIENTTABLE
indicates the XAPI server XCLIENT
shared segment.
XUDBTABLE
indicates the XAPI server XUDB
shared segment.
optionally lists the XAPI server file paths.
optionally lists the XAPI server accept history for the past 24 hours.
optionally lists the XAPI server LOG
setting.
optionally lists the XAPI server MAXCLients
setting.
optionally lists the XAPI server MSGLvl
setting.
optionally lists relevant UNIX system release and resource limits, and XAPI server release, version, and environment settings.
when specified with LIst SERVer
, the PROcess
keyword optionally lists the individual XAPI system processes.
optionally lists the XAPI server TapePlex name.
optionally lists the XAPI server system and work tasks, along with their execution statistics.
optionally lists the XAPI server TRace
setting.
optionally lists relevant XAPI server TCP/IP parameters
when specified with LIst XApi
, the IO
(or I/O
) keyword optionally lists the XAPI server TCP/IP statistics.
optionally lists the XAPI server XCLIent
definitions.
optionally lists the XAPI server XSECurity
setting.
optionally lists the XAPI server XUDB
definitions.
The XCMD LOG
command displays or changes the XAPI server log settings. XAPI server logging optionally enables TCP/IP requests, TCP/IP responses, XAPI server operator commands, console messages, and errors to the XAPI server log file. The XCMD LOG
command is intended to be used primarily as directed by StorageTek Software Support.
As shown in figure, the XCMD LOG
command includes the following parameters:
optionally, displays XAPI server log settings. LIst
is the default when no parameters are specified on the LOG
command.
optionally, turns off all XAPI server log events.
optionally, turns off or on individual XAPI server log events. A string of up to 16 '0
' and '1
' characters may be entered. '1
' turns on the log event, '0
' turns off the log event. The position in the entered string controls individual log events as follows:
1000000000
to log XAPI server error messages to stdout
0100000000
to log XAPI server messages to the log file
0010000000
to log XAPI input request errors to the log file
0001000000
to log XAPI recv packets to the log file
0000100000
to log XAPI send packets to the log file
0000010000
to log XCMD commands and responses to the log file
Note:
Currently string positions 7-16 do not control any XAPI server log settings. If strings longer than 6 characters (but less than 17 characters) are entered, the characters are validated, but subsequently ignored.
LOG 0
is equivalent to LOG OFF
.
Any entered setting completely replaces the prior log settings: Thus if LOG 010001
is followed by LOG 00011
, then following the second LOG
command, neither XAPI messages nor XCMD
commands and responses will be logged to the log file.
The environment variable SMCVLOGFILE
may be used, if specified before XAPI server startup, to override the default XAPI server log file path.
To display the location and name of the XAPI server log file, enter the XCMD LIST FILES
command.
The environment variable SMCVLOG
may be used, if specified before XAPI server startup, to set the XAPI server log settings.
The XCMD MAXCLients
command is used to set an upper limit for the number of concurrent requests that may be active at any one time. When the MAXCLients
limit is reached, any new client requests received by the XAPI server will receive the '503 Service unavailable'
response and should be retried by the client.
As shown in figure, the XCMD MAXCLients
command includes the following parameters:
optionally, displays the XAPI server MAXCLients
setting. LIst
is the default when no parameters are specified on the MAXCLients
command.
optionally, specifies the maximum number of concurrent requests. Enter a number between 1 and 1000.
The XAPI server MSGLvl
command is used to determine the messages that are output to stdout
. Each XAPI server message has a fixed MSGLvl
. When the XAPI server MSGLvl
is greater than the message MSGLvl
, the message is output, otherwise it is suppressed. Thus the higher the XAPI server MSGLvl
, the more verbose the XAPI server messaging.
As shown in figure, the XCMD MSGLvl
command includes the following parameters:
optionally, displays the XAPI server MSGLvl
setting. LIst
is the default when no parameters are specified on the MSGLvl
command.
optionally, specifies the XAPI server MSGLvl
. Enter a number between 0 and 32 as follows:
0
- display startup/shutdown and error messages only.
4
- display warning messages
8
- display additional system status messages
> 8
- display debugging messages; use only at the direction of StorageTek Software Support.
The XCMD TRace
command displays or changes the XAPI server trace settings. XAPI server tracing optionally enables XAPI server component trace events. The XCMD TRace
command is intended to be used solely as directed by StorageTek Software Support.
As shown in figure, the XCMD TRace command includes the following parameters:
optionally, displays XAPI server trace settings. LIst
is the default when no parameters are specified on the TRace
command.
optionally, turns off all XAPI server trace events.
optionally, turns off or on individual XAPI server trace events. A string of up to 16 '0
' and '1
' characters may be entered. '1
' turns on the trace event, '0
' turns off the trace event. The position in the entered string controls individual trace events as follows:
1000000000
to trace XAPI errors
0100000000
to trace XAPI TCP/IP component events
0010000000
to trace PGMI API component events
0001000000
to trace XAPI server thread events
0000100000
to trace XAPI server malloc()
and free()
events
0000010000
to trace XAPI server XML parse events
0000001000
to trace XAPI server command events
0000000100
to trace XAPI server system monitor
0000000010
to trace XAPI server XML, CSV, and text output component events
0000000001
to trace XAPI server logical file events
Note:
Currently string positions 11-16 do not control any XAPI server trace settings. If strings longer than 11 characters (but less that 17 characters) are entered, the characters are validated, but subsequently ignored.
Entering TRACE 0
is equivalent to entering TRACE OFF
.
Any entered setting completely replaces the prior trace settings: Thus if TRACE 010001
is followed by TRACE 00011
, then following the second TRACE
command, neither TCP/IP component events, nor XAPI server malloc()
and free()
events will be traced to the XAPI server trace file.
The environment variable SMCVTRCFILE
may be used, if specified before XAPI server startup, to override the default XAPI server trace file path.
To display the location and name of the XAPI server trace file, enter the XCMD LIST FILES
command.
The environment variable SMCVTRACE
may be used, if specified before XAPI server startup, to set the XAPI server trace settings.
The XAPI server XCLIent
command is used to define XAPI clients that use a different protocol version than the default server XAPI protocol.
Note:
The XCLIent
command is only necessary to define clients that use the older 'unsecured' protocol when XAPI security is enabled (XSECurity ON
). When XSECurity ON
is specified, then any XAPI request that originates from a client that is not defined with a XCLIent
command is assumed to use the newer XAPI security protocol.
If XSECurity OFF
is specified, then XCLIent
definitions are not required.
As shown in figure, the XCMD XCLIent
command includes the following parameters:
optionally, displays XAPI server XCLIent
definitions. LIst
is the default when no parameters are specified on the XCLIent
command.
optionally, specifies the IP resolver host name (HHHHHHHH
) on which the client resides.The HOst
name must be a resolvable name in the TCP/IP name table. The following rules apply:
The value must be between 1 and 255 characters in length.
The first character must be either an alpha character or a digit.
The last character must be either an alpha character or digit.
Any character between the first and last must be either an alpha character, digit, hyphen, or dot.
optionally, specifies the IP address (NN.NN.NN.NN
) for the client.
optionally, specifies the name (CCCCCCCC
) of the client. If the client is SMC/MVS, the NAme
specified should be the name returned as <client_subsystem_name>
. Otherwise the NAme
specified should be the name returned as <client_name>
. If NAme
is specified as '*
', then any request from the specified HOst
or IPaddress
will be defined as using the specified protocol version.
optionally, specifies the range of client ports (NN-NN
) from which the XAPI request originates on the specific HOst
or IPaddress
that are allowed to use the specified protocol version. Valid ports are 1 to 65535, and the range may contain between 10 and 1000 ports.
optionally, specifies the protocol version.
'0
' indicates the older 'unsecure' protocol.
'1
' indicates the new XAPI security protocol version. The default is 0
.
Note:
HOst
and IPaddress
are mutually exclusive.
NAme
and PORTrange
are mutually exclusive.
PORTrange
should be used if the SMC/MVS TCPIP PORTrange
command has been specified to restrict SMC/MVS client ports to the specified range.
The XAPI server XSECurity
command is used to globally enable or disable the XAPI security protocol for the XAPI server.
When XAPI security protocol is enabled, then user password security will be enforced for any requests received by the XAPI server.
Note:
When XAPI security is globally enabled, individual clients may be 'exempted' from XAPI security if they are the specified in an XCLIent
definition.
When XAPI security is globally enabled, then the same user and password must be defined on both the client and server. XAPI security users and passwords are normally specified using XUDB
definitions, but see the notes in the XUDB
command concerning XAPI security users under the Virtual Storage Manager console (VSMc).
As shown in figure, the XCMD XSECurity
command includes the following parameters:
optionally, displays the XAPI server XSECurity
setting. LIst
is the default when no parameters are specified on the XSECurity
command.
optionally, enables XAPI security.
optionally, disables XAPI security.
The XAPI server XUDB
command is used add, update, delete, and list XAPI security users. The XAPI security user list is maintained by both the client and server.
Note:
The same XUDB USER
must be defined on both the client and server.
If XSECurity OFF
is specified, then XUDB definitions are not required.
As shown in figure, the XCMD XUDB
command includes the following parameters:
optionally, displays XAPI server XUDB definitions. LIst
is the default when no parameters are specified on the XUDB
command.
specifies that the specified user name and password is to be added to the XAPI security user list.
specifies the name to be added. The USER
name need not be a defined UNIX user name, so long as the same name and password are defined in both the client and server. The USER
name may be up to 20 characters in length.
specified the password for the specified USER
. The PASSword
may be up to 20 characters in length.
specifies that the specified user name is updated in the XAPI security user list with the specified PASSword
.
specifies the name to be updated.
specified the new password for the specified USER
.
specifies that the specified user name is deleted in the XAPI security user list.
specifies the name to be deleted.
specifies that the specified user name from the XAPI security user list is to be listed.
specifies the name to list. If USER
is not specified then all names are listed.
Note:
When the XAPI server is a component of the Virtual Storage Management console (VSMc), the XAPI server uses VSM console facilities to add, update and delete XAPI security users. While XUDB ADD
commands may be issued on the VSM console, it is recommended that you use the VSM console TUI to maintain XAPI security users.
If an XUDB ADD
, UPDate
, or DELete
command is issued on VSM console, the VSM console user database is updated.
In VSM console, a XUDB LIST
command will simply state that users are maintained in the VSM console user database.
The VSM GUI supplied with the VSM console enables you to view a running system log for console operator messages generated from the oVTCS instances running on each VSM console server.
To view the console log:
Start the VSM GUI application.
Access the VSM Console menu.
Select the Console Log tab.
Select the tapeplex from the Tapeplex menu to populate the Console Log with messages from that tapeplex.
Three types of messages are displayed:
WTO (Write to Operator)
WTOR (WTO with Reply)
HILITE (highlighted WTO)
There are two tables on the Console Log page:
The WTORs and HILITEs table lists WTOR and HILITE messages for the selected tapeplex. Messages are displayed in chronological order sorted by message type, with the most recent at the bottom.
Certain fields include a context menu indicator. Right-click on these fields to access the context menu, enabling you to perform actions including replying to WTOR messages or deleting messages.
The Log table lists WTO messages and replied to or deleted WTOR and HILITE messages. Messages are displayed in chronological order sorted by message type, with the most recent at the bottom.
Refer to the VSM GUI User's Guide for more detailed information about using the VSM console Console Log.