Your Browser is not longer supported

Please use Google Chrome, Mozilla Firefox or Microsoft Edge to view the page correctly
Loading...

{{viewport.spaceProperty.prod}}

Prerequisites and installation

SANCHECK is supported on /390 server.

SANCHECK uses functions of the following components:

  • POSIX-BC (must be operational)

  • CRTE-BASYS (must be available)

SANCHECK supports the switches of Brocade Communications Systems, Inc. The precise type designations can be found in the Release Notices for BS2000.

Execution of SANCHECK under the SERVICE user ID

SANCHECK can execute under the SERVICE user ID (with the HARDWARE-
MAINTENANCE privilege) if module library SINLIB.SANCHECK.<version> has been assigned the access attribute USER-ACCESS=SPECIAL and in the INI file the SWITCHES file has been specified with the ($TSOS) user ID (SWIFILE, NAME=$TSOS.SYSDAT.SANCHECK.SWITCHES).

In addition, the following BS2000 module libraries must have the access attribute USER-ACCESS=SPECIAL:

  • SYSLNK.CRTE-BASYS

  • SINLIB.POSIX-BC.<version>

Ascertaining the WWNN

SANCHECK must at least know one of the WWNNs of the local server in order to ascertain the Fibre Channel configuration data. This WWNN must be specified in the SANCHECK-INI file (see "INI file") since SANCHECK cannot ascertain it itself using operating system functions. When a server has multiple Fibre Channel adapters, any of the WWNNs is specified.

The WWNN is ascertained using the SVP:

  • Open SVP-FRAME

  • Call MODE SELECTION FRAME

  • Select CH (CH/SUBCH STATUS) and in this way call the CH/SUBCH STATUS DISPLAY FRAME

  • Call function 4 (FC PORT STATUS):

  • The SELF CL-NAME field contains the WWNN

The SVP frames are described in detail in the operating instructions for the /390 servers.

On SE servers the WWNN can be determined in the same manner using the functions of the SVP console. The SVP console can be opened in the BS2000 operation mode tab in the SE Manager (Server Unit /390 selected).

 

Communication with the Fibre Channel switches

SANCHECK determines the configuration data of the FC switches through read-only access to the switches’ SNMP agents (see also "SANCHECK - Checking the SAN configuration"). To permit this, a LAN connection is required from the BS2000 system to all switches in the fabric.

This LAN connection between the BS2000 system and a Fibre Channel switch must be known in BCAM. A distinction must be made between the following cases here:

  • Automatic configuration extension in BCAM is disabled (BCAM statement BCOPTION AUTOMATIC-ES-CREATE=OFF(PROFILE=IP,...) ): A route for the LAN connection between the BS2000 system and the switch must be defined.

  • Automatic configuration extension in BCAM is enabled: Access to the Fibre Channel switch is controlled by the BCAM processor table (default name:
    $TSOS.SYSDAT.BCAM.PROCESSORS):

    • If the latter has the attribute ACCESS=UPDATE (BCAM statement /BCMOD PROCESSOR-TABLE=(ACCESS=UPDATE)), the switch is automatically included in the BCAM configuration in response to the data request.

    • If the PROCESSOR-TABLE has the attribute ACCESS=READ, communication is only possible with the switches which are entered in the BCAM processor table with a selectable processor name and their IP address. For details, please refer to the manuals BCAM [11 (Related publications)].

Prerequisites for the Fibre Channel switches

SANCHECK uses the FA-MIB (FibreAlliance Management Information Base) to ascertain the data. It may therefore not be disabled for the switches (for switches of the vendor Brocade this is done with the CLI command snmpConfig, and in old firmware versions with snmpMibCapSet). If the FA-MIB is disabled, SANCHECK issues a warning message, but continues processing. In this case the switch data is incomplete.

If access control is set up on a switch by means of an “Access Control List”, the BS2000 system’s IP address must be entered there.

SANCHECK uses the SNMPv1 or SNMPV3 protocol. When a virtual fabric is to be checked, the SNMPv3 protocol must be used. The selection is made when a switch is defined in the SANCHECK-SWITCHES file.

The functions required by SANCHECK to ascertain the SAN configuration are based on functions for network administration of the switches to be monitored. Depending on the vendor, these functions can be optional and may require separate licenses. Details on this can be obtained from the documentation for the particular switch.

The following applies for the use of the SNMPv1 protocol:

A community name which permits read-only access to the SNMP database must be stored on each of the switches to be checked. For most switches the community name “public” is defined by default. This is the default value which SANCHECK uses when nothing else is specified in the SWITCHES file (see section "SWITCHES file").

 

The following applies when the SNMPv3 protocol is used:

On each of the switches to be checked an SNMP user ID must be defined which may access the SNMP database in read mode. In the case of the switches of the vendor Brocade, the names snmpuser1, snmpuser2 and snmpuser3 are defined by default. SANCHECK employs the user ID sancheck with the password password by default if nothing else has been specified in teh SWITCHES file (see section "SWITCHES file").


The following applies for switches of the vendor Brocade (firmware versions 6.4.3 and higher):

On each of the switches to be checked a user ID with minimal rights must be defined in the switch operating system FOS. This may only perform information functions, but may not make any changes to the switch configuration. This user ID is called switch user below (to distinguish it from the SNMP user).

If SANCHECK has no user ID available, the zoning data cannot be determined, and the SAN configuration check is incomplete.

SANCHECK employs the user ID sancheck with the password password by default if nothing else has been specified in teh SWITCHES file (see section "SWITCHES file").

When the SNMPv3 protocol is employed, the SNMP user name and the switch user name must be identical because SANCHECK manages only a single name per switch.

Installation in BS2000

SANCHECK is installed in BS2000 using the IMON installation monitor.

Release unit

Function

SYSLNK.SANCHECK.<version>

Module library for /390 servers

SKMLNK.SANCHECK.<version>

Module library for x86 servers (obsolete)

SINLIB.SANCHECK.<version>

Library with installations components

SYSMES.SANCHECK.<version>

Message file

SYSSDF.SANCHECK.<version>

SDF syntax file

SYSSSC.SANCHECK.<version>

Subsystem definition

SYSSII.SANCHECK.<version>

Structure information

SYSDAT.SANCHECK..INI

Default INI file

SYSDAT.SANCHECK..SWITCHES

Default SWITCHES file

SYSRME.SANCHECK.<version>.D/E

Readme file (German/English)

SYSFGM.SANCHECK.<version>.D/E

Release Notice (German/English)

SYSDOC.SANCHECK.<version>.OSS

Library with Open Source license information

Table 17: Delivery components of SANCHECK

 

Installation in POSIX

After SANCHECK has been installed, a few SANCHECK components must be installed in POSIX. This is done using the POSIX installation program, see the ”POSIX Basics for Users and System Administrators” manual [19 (Related publications)].

Example

/START-POSIX-INSTALLATION

Funktion: POSIX-Programmpakete installieren (IMON-Unterstützung: Y)

Produktname: SANCHECK

Produktversion: <version>

SANCHECK subsystem

The SANCHECK subsystem must be loaded before the SANCHECK utility routine is started for the first time. This makes the SDF syntax file and the message file available:

/START-SUBSYSTEM SUBSYSTEM-NAME=SANCHECK

The SANCHECK subsystem is terminated by means of:

/STOP-SUBSYSTEM SUBSYSTEM-NAME=SANCHECK

If, at this time, the SANCHECK utility routine is still in use, the subsystem remains in the IN DELETE / WAIT-DISCON state until usage comes to an end.