5 oVTCS Operational Considerations

This chapter describes software considerations for oVTCS, the version of VTCS that runs on the VSM console server.

oVTCS Functions

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.

Defining oVTCS Policy Parameters

This section describes the oVTCS policy parameter file and how to activate this file in your VSM console configuration.

oVTCS Policy Parameter File

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.

Required Statements

The oVTCS policy parameter file must include at least one instance of each of the following statements:

Note:

With the exception of TAPEPLEX, the following statements closely match the ELS usage. Refer to your Oracle StorageTek ELS publications for more information about these statements.
POOLPARM

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.
VOLPARM

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.

STORCLAS

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.

MGMTCLAS

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.

TAPEPLEX

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:

  1. In the oVTCS policy parameter file, update the TAPEPLEX statement to remove the P address of the node requiring maintenance.

  2. Issue the oVTCS MGMTDEF ACTIVATE command with the updated parameter file.

  3. Perform maintenance on the node that was removed.

  4. Update the TAPEPLEX statement to re-add the node IP address.

  5. Issue the oVTCS MGMTDEF ACTIVATE command to load the updated parameter file.

Optional Statements

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.
OPTION

This statement specifies an identifying string (name) for the file.

MIGRSEL

These statements specify migration request settings for managing migrates to storage classes from VTSSs.

MIGRVTV

These statements specify migration request settings for individual VTV copies processed by immediate migration.

MVCATTR

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.

STORLST

These statements specify lists of storage classes and their corresponding preferencing.

STORSEL

These statements specify storage class usage rules that apply to the Storage Class list and its preferencing specified on a referenced STORLST control statement.

VTSSLST

These statements specify a list of VTSSs and their corresponding preferencing.

VTSSSEL

These statements specify storage class usage rules that apply to the VTSS list and its preferencing specified on a referenced VTSSLST control statement.

CMDEXEC

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.

Loading the oVTCS Policy Parameter File Using the SMCUUUI Utility

To activate the oVTCS policy parameter file in a mainframe configuration, use the SMC SMCUUUI utility to issue the oVTCS MGMTDEF command.

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 oVTCS MGMTDEF command is a native oVTCS command, and is not related to the SMC MGMTDEF command.
Syntax

Figure 5-1 shows syntax for the oVTCS MGMTDEF command statement:

Figure 5-1 oVTCS MGMTDEF command syntax

Surrounding text describes Figure 5-1 .
Parameters

As shown in Figure 5-1, the oVTCS MGMTDEF command includes the following parameters:

ACTIVATE

optionally, validate the parameters contained in the specified oVTCS parameter file and then activate these parameter settings.

Note:

If you do not specify the ACTIVATE parameter, the parameters contained in the specified oVTCS parameter file are only validated.
LIST

optionally, list the parameters that are read from the oVTCS parameter file.

Example

The following example shows the MGMTDEF command with the ACTIVATE parameter as specified in the SMCUUUI utility UUIIN statement:

Example 5-1 MGMTDEF ACTIVATE command

//UUIIN    DD  *
    SDD DDNAME(INPARMS) INPUT TEXT
    MGMTDEF ACTIVATE

In the example above, the MGMTDEF ACTIVATE command indicates to validate and activate the oVTCS parameter file, named INPARMS.

Loading the oVTCS Policy Parameter File Using the VSM GUI

To activate the oVTCS policy parameter file using the VSM GUI supplied with the VSM console:

  1. Start the VSM GUI application.

  2. Access the VSM Console menu. This menu includes the following options:

    • Command Line Interface (CLI)

    • Configuration/Policy

    • Console Log

  3. Select the VSMc Configuration/Policy tab. This page enables you to download, edit, and upload an oVTCS Policy file that defines oVTCS policy settings.

  4. Select the tapeplex name from the menu.

  5. Select the server address from the menu. Only server addresses configured for the selected tapeplex are listed.

  6. Click the Download button to specify your policy parameter file and load it into the VSM GUI.

  7. Click the Edit button to make any desired edits to the file.

  8. 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.

oVTCS Command Considerations

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 Operator and Administrator Commands

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.

    1. Start the VSM GUI application.

    2. Access the VSM Console menu.

    3. 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.

    4. Select the tapeplex and the appropriate node server address.

    5. 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

oVTCS XAPI Server Component Operator and Administrator Commands

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.

XCMD LIst command

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.

Syntax

Figure 5-2 shows syntax for the XCMD LIst command.

Figure 5-2 XCMD LIst command syntax

Surrounding text describes Figure 5-2 .

Parameters

As shown in figure, the XCMD LIst command includes the following parameters:

ALl

optionally, displays all XAPI server parameters and environment variables. ALl is the default when no parameters are specified on the LIst command.

CB NNNN or NNNN-IIII

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.

FILEs

optionally lists the XAPI server file paths.

HISTory

optionally lists the XAPI server accept history for the past 24 hours.

LOG

optionally lists the XAPI server LOG setting.

MAXCLients

optionally lists the XAPI server MAXCLients setting.

MSGLvl

optionally lists the XAPI server MSGLvl setting.

SERVer

optionally lists relevant UNIX system release and resource limits, and XAPI server release, version, and environment settings.

PROcess

when specified with LIst SERVer, the PROcess keyword optionally lists the individual XAPI system processes.

TAPEPlex

optionally lists the XAPI server TapePlex name.

TASKs

optionally lists the XAPI server system and work tasks, along with their execution statistics.

TRace

optionally lists the XAPI server TRace setting.

XApi

optionally lists relevant XAPI server TCP/IP parameters

IO or I/O

when specified with LIst XApi, the IO (or I/O) keyword optionally lists the XAPI server TCP/IP statistics.

XCLIent

optionally lists the XAPI server XCLIent definitions.

XSECurity

optionally lists the XAPI server XSECurity setting.

XUDB

optionally lists the XAPI server XUDB definitions.

XCMD LOG command

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.

Syntax

Figure 5-3 shows syntax for the XCMD LOG command.

Figure 5-3 XCMD LOG command syntax

Surrounding text describes Figure 5-3 .

Parameters

As shown in figure, the XCMD LOG command includes the following parameters:

LIst

optionally, displays XAPI server log settings. LIst is the default when no parameters are specified on the LOG command.

OFF

optionally, turns off all XAPI server log events.

1 or 0

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.

Example

In the following example, the LOG command logs both XAPI recv and send packets to the log file:

LOG 00011

XCMD MAXCLients command

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.

Syntax

Figure 5-4 shows syntax for the XCMD MAXCLients command.

Figure 5-4 XCMD MAXCLients command syntax

Surrounding text describes Figure 5-4 .

Parameters

As shown in figure, the XCMD MAXCLients command includes the following parameters:

LIst

optionally, displays the XAPI server MAXCLients setting. LIst is the default when no parameters are specified on the MAXCLients command.

NNNN

optionally, specifies the maximum number of concurrent requests. Enter a number between 1 and 1000.

XCMD MSGLvl command

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.

Syntax

Figure 5-5 shows syntax for the XCMD MSGLvl command.

Figure 5-5 XCMD MSGLvl command syntax

Surrounding text describes Figure 5-5 .

Parameters

As shown in figure, the XCMD MSGLvl command includes the following parameters:

LIst

optionally, displays the XAPI server MSGLvl setting. LIst is the default when no parameters are specified on the MSGLvl command.

NN

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.

XCMD TRace command

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.

Syntax

Figure 5-6 shows syntax for the XCMD TRace command.

Figure 5-6 XCMD TRace command syntax

Surrounding text describes Figure 5-6 .

Parameters

As shown in figure, the XCMD TRace command includes the following parameters:

LIst

optionally, displays XAPI server trace settings. LIst is the default when no parameters are specified on the TRace command.

OFF

optionally, turns off all XAPI server trace events.

1 or 0

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.

Example

In the following example, the TRace command traces both XAPI server thread and process events and XAPI server malloc() and free() events to the XAPI server trace file:

TRace 00011

XCMD XCLIent command

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.

Syntax

Figure 5-7 shows syntax for the XCMD XCLIent command.

Figure 5-7 XCMD XCLIent command syntax

Surrounding text describes Figure 5-7 .

Parameters

As shown in figure, the XCMD XCLIent command includes the following parameters:

LIst

optionally, displays XAPI server XCLIent definitions. LIst is the default when no parameters are specified on the XCLIent command.

HOst HHHHHHHH

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.

IPaddress NN.NN.NN.NN

optionally, specifies the IP address (NN.NN.NN.NN) for the client.

NAme CCCCCCCC

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.

PORTrange NN-NN

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.

PROTver [0|1]

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.

XCMD XSECurity command

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).

Syntax

Figure 5-8 shows syntax for the XCMD XSECurity command.

Figure 5-8 XCMD XSECurity command syntax

Surrounding text describes Figure 5-8 .

Parameters

As shown in figure, the XCMD XSECurity command includes the following parameters:

LIst

optionally, displays the XAPI server XSECurity setting. LIst is the default when no parameters are specified on the XSECurity command.

ON

optionally, enables XAPI security.

OFF

optionally, disables XAPI security.

XCMD XUDB command

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.

Syntax

Figure 5-9 shows syntax for the XCMD XUDB command.

Figure 5-9 XCMD XUDB command syntax

Surrounding text describes Figure 5-9 .

Parameters

As shown in figure, the XCMD XUDB command includes the following parameters:

LIst

optionally, displays XAPI server XUDB definitions. LIst is the default when no parameters are specified on the XUDB command.

ADD

specifies that the specified user name and password is to be added to the XAPI security user list.

USER UUUUUUUU

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.

PASSWORD PPPPPPPP

specified the password for the specified USER. The PASSword may be up to 20 characters in length.

UPDate

specifies that the specified user name is updated in the XAPI security user list with the specified PASSword.

USER UUUUUUUU

specifies the name to be updated.

PASSWORD PPPPPPPP

specified the new password for the specified USER.

DELete

specifies that the specified user name is deleted in the XAPI security user list.

USER UUUUUUUU

specifies the name to be deleted.

LIst

specifies that the specified user name from the XAPI security user list is to be listed.

USER UUUUUUUU

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.

Viewing the oVTCS Console Log

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:

  1. Start the VSM GUI application.

  2. Access the VSM Console menu.

  3. Select the Console Log tab.

  4. 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.