Chapter 3
Verifying the 1.7.5 Console Software


3.1 Verifying the Installation Directories

Log in as administrator.

Use the Windows NT Explorer (located under the Programs menu from the Start button) to verify the installation directories located under the c:\vcs folder.

The installation creates the following directories:

c:\vcs\Ara
Contains the files for the Automatic Remote Application files.
c:\vcs\bin
Contains the VCS and NUMA-Q Online Diagnostics files.
c:\vcs\help
Contains the .man style files for VCS commands and scripts.
c:\vcs\log
Default location for VCS log files.
c:\vcs\OflDiags
Contains the NUMA-Q Offline Diagnostics binary files.
c:\vcs\QuadDOS
Contains support files for third-party diagnostics requiring DOS.
c:\vcs\quadfw
Contains subdirectories for the hardware specific BIOS files, operating system specific files, and other firmware files.
c:\vcs\scripts
Default location for startup.txt and other VCS CLI script files.
c:\vcs\tsl
Default location for NUMA-Q Online Diagnostics test scripts (.tsl).


3.2 Verifying the Console Software Group

  1. Click the Start button.

  2. From the Programs menu, open the Console Software 1.7.5 menu. The menu should contain the following:

    Edit startup.txt
    Edits the startup.txt file.
    VCS
    Starts VCS version 1.7.5.
    VCS Help
    Starts the VCS online help.
    VCS Registry Setup
    Starts the VCS registry editor.
    View log file
    Displays the current VCS log entries, up to the point when the file is viewed. This is not an interactive view.


3.3 Editing the startup.txt File

If you had an existing startup.txt file, it is preserved. The new startup file off the media is saved as startup.tx_ in the same directory. It is not necessary to edit the startup.txt file, although you may want to add site specific information. To edit this file:

  1. Click on Start.

  2. From the Console Software 1.7.5 menu (from the Programs menu), click on Edit startup.txt. A Notepad window is displayed.

  3. At a minimum, this file should contain:

    waitstate OS1 != "Config Mgmt" 
    cd /system_name
    
    where system_name is the name you assigned with the sysdef command. The waitstate command instructs VCS to wait until the appropriate state is reached before attempting to issue additional commands.

  4. When the edits are complete, select File -> Save.

  5. Select File -> Exit.


3.4 Starting VCS

  1. Click on Start.

  2. From the Console Software 1.7.5 menu (from the Programs menu), click on VCS. The VCS Main Menu and a Command Line Interpreter window are automatically started.


3.4.1 Defining Systems

You must define your system the first time you start VCS, by assigning a system name and number, and specifying which Quads and components belong to which system. Use the sysdef command to perform the definition. System definitions are preserved during upgrades.

Refer to the VCS online help (press F1 in the VCS CLI window) for specifics on the sysdef command. Here is a basic example of the sysdef command. To determine the components available:

->sysdef -l
Unassigned Mdc(s)
MDC0:Quad_3701000  State: Active Net: 138.95.158.100 (8.0.47.2.0.42)
MDC1:Quad_3601060  State: Active Net: 138.95.158.102 (8.0.47.2.0.45)
MDC2:Lash_0700027  State: Active Net: 138.95.158.101 (8.0.47.2.0.52)
In this case, we are defining a system named numaq1, system number 1, composed of two Quads Quad_3701000 and Quad_3601060 and an IQ-Ring Module Lash_0700027. From the VCS CLI window, type:
->sysdef -c numaq1 1 Quad_3701000 Quad_3601060 Lash_0700027
'numaq1' created successfully
->sysdef -l
System1: numaq1   State: Quad/Lash detect done  AutoActivate: On
MDC0:quad0 (Quad_3701000) State: Active  Net: 138.95.158.100 (8.0.47.2.0.42)
MDC1:quad1 (Quad_3601060) State: Active  Net: 138.95.158.102 (8.0.47.2.0.45)
MDC2:lash2 (Lash_0700027) State: Active  Net: 138.95.158.101 (8.0.47.2.0.52)


ATTENTION

Do not delete a system when the system state is Config Mgmt, Activating.



3.4.2 Flashing Firmware


ATTENTION

If the VCS Command updateprocinfo is used, you must wait for at least 60 seconds for the command to finish to ensure the information is completely written to the Diary RAM cache. After waiting the 60 seconds, shutdown and restart VCS.



3.4.2.1 Automatically Flashing All Firmware and System Files


ATTENTION

Before you flash the MDC firmware, verify that the NUMA-Q system DC power is on, the AC power breakers for the individual MDCs (all quad types and IQ-Ring Modules (LASHs)) are ON, and the system is in the state HELD_RESET. If there is an open Console window (not the VCS CLI window) it is recommended that you close it prior to flashing. Otherwise, you may get error messages indicating that the MDC firmware update failed.


The /vcs/scripts/flash script can be used to automatically flash the MDC firmware on all quads, and IQ-Ring modules, the system files on all quads, and the SBB and QBB BIOS. The script flashes new components based on the current system information (obtained from fwcheck), and the approved firmware gold versions (obtained from fwgold).


ATTENTION

If any errors occur when running the script, re-flash the components with the manual instructions in sections 3.4.2.2 3.4.2.3 and 3.4.2.4


To run the script:

  1. Open a CLI window on the console.

  2. Connect to the system to be flashed. For example, cd sys_name

  3. Type: flash

A list of available ptx versions is displayed. Type the option number (appearing in the parenthesis) and press Enter. The script flashes only the firmware components necessary for each quad or IQ-Ring module. If the OTHER choice is selected, flash does not update the OS firmware.


ATTENTION

Select the option for your operating system version. Select 4.4.6 for DYNIX/ptx versions 4.4.4, 4.4.5, and 4.4.6. The 4.4.6 sak.dat and ptxldr.elf files support ptx 4.4.4 through 4.4.6.



3.4.2.2 Manually Flashing MDC Firmware and System Files on SQuads and Quads


ATTENTION

Before you flash the MDC firmware, verify that the NUMA-Q system DC power is ON, the AC power breakers for the individual MDCs (all quads and IQ-Ring Modules (LASHs)) are ON, and the system is in the state HELD_RESET. If there is an open Console window (not the VCS CLI window) it is recommended that you close it prior to flashing. Otherwise, you may get error messages indicating that the MDC firmware update failed.


Use the following VCS CLI commands for all quads in your system. For the operating system specific files (sak.dat and ptxldr.elf), substitute the [OS_DIR] variable with the name of the subdirectory for the release to be flashed, for example ptxv4_4_8 or ptxv4_5_1. If you are using either ptx 4.4.4, 4.4.5 or 4.4.6, use the files in the ptxv4_4_6 directory. The 4.4.6 sak.dat and ptxldr.elf files support ptx 4.4.4, 4.4.5, and 4.4.6.

cd /system_name
->cd quad0 
->mdcflash -d quad.elf 
->mdcflash -w c:/vcs/quadfw/quad.elf 
->mdcflash -d lynxer.elf 
->mdcflash -w c:/vcs/quadfw/lynxer.elf 
->mdcflash -d sak.dat
->mdcflash -w c:/vcs/quadfw/os/ptx/[OS_DIR]/sak.dat 
->mdcflash -d ptxldr.elf
->mdcflash -w c:/vcs/quadfw/os/ptx/[OS_DIR]/ptxldr.elf
->mdcflash -u c:/vcs/quadfw/mdcapp.bin

The mdcflash -l command lists the names of the files that are currently flashed. Look for a file with an .obj suffix. If this file is named anything other than str3_20.obj (Quads), dstr2_20.obj (SQuads), cstr2_22.obj (CQuads) or cmstr2_23.obj (Midrange CQuad), it must be deleted and the new file flashed. The getmdctype command can be used to determine if it is a CQuad, MQuad or SQuad (SCORP_QUAD) or a Quad (STING_QUAD). For example, if the existing Quad file is named sfw1_01.obj:

->mdcflash -l
->mdcflash -d sfw1_01.obj 
->mdcflash -w c:/vcs/quadfw/hw/sting1/str3_20.obj
->bootflags lynxerseqcodepath str3_20.obj
->cd .. 
Repeat this process (starting with cd /quad1) for each Quad.

For an SQuad:

->mdcflash -l
->mdcflash -w c:/vcs/quadfw/hw/sting2/scorpion/dstr2_20.obj
->bootflags lynxerseqcodepath dstr2_20.obj
->cd .. 

For an MQuad:

->mdcflash -l
->mdcflash -w c:/vcs/quadfw/hw/sting2/billings/bstr2_23obj
->bootflags lynxerseqcodepath bstr2_23obj
->cd .. 

For an CQuad:

->mdcflash -l
->mdcflash -w c:/vcs/quadfw/hw/sting2/centurion/cstr2_22.obj
->bootflags lynxerseqcodepath cstr2_22.obj
->cd .. 

For an Midrange CQuad:

->mdcflash -l
->mdcflash -w c:/vcs/quadfw/hw/sting2/cmidrange/cmstr2_23.obj
->bootflags lynxerseqcodepath cmstr2_23.obj
->cd .. 


3.4.2.3 Manually Flashing the IQ-Ring Modules (LASH)

The NUMA-Q system DC power should still be off before flashing MDC firmware.

Use the following VCS CLI command (assuming the firmware files are in the default location) for any IQ-Ring modules (lash2 in this example) in your system:

->cd lash2 
-> mdcflash -u c:/vcs/quadfw/mdcapp.bin


3.4.2.4 Manually Updating the SBB and QBB BIOS


ATTENTION

The MDC firmware must be flashed before updating the SBB or QBB BIOS.


The getmdctype command can be used to determine if the quad is an MQuad, CQuad, SQuad, or midrange CQuad (SCORP_QUAD) or a Quad (STING_QUAD). Use the sbbupdatebios command for the MQuad, CQuad, SQuad, and midrange CQuad, and the qbbupdatebios command for the Quads.

By default, the BIOS versions 1.7.5 and 1.7.4 are located in c:\vcs\quadfw\hw\sting2\s1_7_5.bin and c:\vcs\quadfw\hw\sting1\q1_7_4.bin. The file image contains two parts: the operational BIOS, and a 'RAM-less' monitor program. The sbbupdatebios and qbbupdatebios commands with the -v and -c options invoke the existing RAM-less monitor installed in the BIOS ROM on the Quad baseboards. VCS communicates with the RAM-less monitor to write the operational BIOS. After this is successful, running the sbbupdatebios and qbbupdatebios commands with the-v, -c and -r options causes VCS to communicate with the newly installed operational BIOS to update the RAM-less monitor.

Use this two-step procedure to update the SBB BIOS:

  1. Update the MQuad, CQuad, SQuad, or midrange CQuad SBB BIOS first, without updating the RAM-less monitor (no -r switch):

    -> cd /system_name
    -> cd quad5
    -> sbbupdatebios -v -c c:/vcs/quadfw/hw/sting2/s1_7_5.bin
    
  2. Wait until the CLI prompt returns. If an error occurs, try the sbbupdatebios command again. If this command completes without an error message, go ahead and update the RAM-less monitor:

    -> sbbupdatebios -v -c -r c:/vcs/quadfw/hw/sting2/s1_7_5.bin
    -> cd ..
    
  3. When complete, repeat for all of the other MQuads, CQuads, SQuads, or midrange CQuads in your system. If this is performed in a script, use the errcount command to ensure that the RAM-less monitor is not updated if the BIOS update fails:

    errcount -e0 -a1 
    sbbupdatebios -v -c c:/vcs/quadfw/hw/sting2/s1_7_5.bin
    sbbupdatebios -v -c -r c:/vcs/quadfw/hw/sting2/s1_7_5.bin
    

    The errcount command causes the script to be aborted in case of an error.

Use this two-step procedure to update the Quad QBB BIOS:

  1. Update the QBB BIOS first, without updating the RAM-less monitor (no -r switch):

    -> cd /system_name
    -> cd quad0
    -> qbbupdatebios -v -c c:/vcs/quadfw/hw/sting1/q1_7_4.bin
    
  2. Wait until the CLI prompt returns. If an error occurs, try the qbbupdatebios command again. If this command completes without an error message, go ahead and update the RAM-less monitor:

    -> qbbupdatebios -v -c -r c:/vcs/quadfw/hw/sting1/q1_7_4.bin
    -> cd ..
    
  3. When complete, repeat for all of the other Quads in your system. If this is performed in a script, use the errcount command to ensure that the RAM-less monitor is not updated if the BIOS update fails:

    errcount -e0 -a1 
    qbbupdatebios -v -c c:/vcs/quadfw/hw/sting1/q1_7_4.bin
    qbbupdatebios -v -c -r c:/vcs/quadfw/hw/sting1/q1_7_4.bin  
    

    The errcount command causes the script to be aborted in case of an error.


3.4.3 Powering up and Booting the NUMA-Q System

If you have upgraded to DYNIX/ptx 4.4.4 and higher, 4.5.x, or 4.6.x, read the DYNIX/ptx 4.4.4 and higher, 4.5.x, or 4.6.x and Layered Products Software Installation Release Notes for information on installing and configuring the software on the NUMA-Q system.


3.4.3.1 Enabling Console-less Reboot

VCS can be set up to reboot the NUMA-Q system when the console is either disconnected or unresponsive.


ATTENTION

The console-less reboot feature and the automatic fault reconfiguration feature cannot be used simultaneously.


To set up VCS to perform a console-less reboot of the NUMA-Q system:

  1. Open a VCS CLI Window for the system from the VCS Main Menu.

  2. Type the following commands (where sys_name is the name of your system):

    -> cd /sys_name/quad0
    -> bootflags
    

  3. The values for faultreboot, iprequestdelayand waitforvcsshould be set to 1, 0, and at least 40 seconds to enable a console-less reboot. To set a bootflag, use the Settings button on the Console front panel or one or more of the following VCS CLI commands:

    -> cd /sys_name/quad0
    -> bootflags faultreboot 1
    -> bootflags iprequestdelay 0
    -> bootflags waitforvcs 60
    

The LED on the Quads and IQ-Ring Modules shows the current state of the NUMA-Q system components during a console-less reboot.



Figure 3-1. LED Readouts during Console-less Reboot.


The LED readouts are as follows: (1) Initial LED display. (2) The 7-segment display on MDC0 changes from the initial upsidedown U to C when MDC0 starts attempting to connect to the other MDCs. (3) Indicates a Quad is Listening for MDC0. The display changes to C when connected. Quads are connected in ascending order from the sysinfo table. Once MDC0 determines the system is ready to boot, the display on all Quads should show a top bar (4). Any IQ-Ring module LEDs should indicate the (1). (4) Lynxer start (Quads only) As various stages of lynxer complete, an additional segment is turned on as follows: (5) Lynxer QMI Request Services (6) Lynxer Syncs received (7) Lynxer Complete. Begin loading sak.dat.

Once the VCS console is reconnected, the displays change to the appropriate number for that Quad. Once the system is given a reasonable time to complete boot, use telnet to contact the server and log in, or reconnect the console to confirm the OS is up.


3.4.3.2 Automatically Powering on the NUMA-Q System


ATTENTION

The console-less reboot feature and the automatic power-on/fault reconfiguration feature cannot be used simultaneously.


To set up VCS to automatically power up and boot the NUMA-Q system:

  1. Open a VCS CLI Window for the system from the VCS Main Menu.

  2. Type the following commands (where sys_name is the name of your system):

    -> cd /sys_name/quad0
    -> bootflags
    

  3. The values for autoboot, faultreconfig and faultreboot should be set to 1 if you want the system to always try to reboot after a power failure or a quad failure. To set a bootflag to 1, use the Settings button on the Console front panel or one or more of the following commands:

    -> cd /sys_name/quad0
    -> bootflags autoboot 1
    -> bootflags faultreconfig 1
    -> bootflags faultreboot 1
    

Turn on the AC power to the system. The system boots to either single user or multi user mode, depending on the setting in the /etc/inittab file.


3.4.3.3 Manually Powering on the NUMA-Q System

To manually power up and boot the NUMA-Q system from VCS:

  1. Open a Console Window for the system from the VCS Main Menu. Select the system from the left pane and select Console from the right pane.

  2. When the Console front panel is displayed, move the Power slider switch to the ON position.

  3. When the green indicator light is on, click on the Boot button to begin booting.


3.4.4 Installing Online Diagnostics on the NUMA-Q System

In addition to installing the Online Diagnostics on the system console PC, there is a portion of the diagnostics that must be installed on the NUMA-Q system. Refer to the DYNIX/ptx 4.4.4 and higher, 4.5.x, or 4.6.x and Layered Products Software Installation Release Notes for installation information.


ATTENTION

DYNIX/ptx 4.4.x, use the 2.6.x Online Diagnostics. DYNIX/ptx 4.5.x uses the 2.7.x version of the Online Diagnostics.


For SQuads and CQuads, several operating system parameters must be changed to run the Online Diagnostics:

Increase the maximum shared memory segment size (SHMMAX) to 81920000

Increase the shared memory identifiers (SHMMNI) to 200

Refer to the DYNIX/ptx System Configuration and Performance Guide for information on changing operating system parameters.


3.5 VCS Log Server on ptx

The vcslogserver is a server process that executes on the NUMA-Q system. This process is required if the destination of the logbackup command is a directory on the NUMA-Q system.


3.5.1 Configuring the Server

The server can be configured three different ways:

  1. Accept connections only from the QMI

    vcslogserver -d /tmp

    The VCS log server is started and accepts connections only from the QMI. The top level directory that log files can be backed up to is /tmp (-d /tmp). No TCP/IP socket will be opened and connections from across the public LAN are not accepted.

  2. Accept connections only from the Public LAN

    vcslogserver -Q -m host_name1,host_name2,IP_addr

    The VCS log server is started and accepts connections only from the public LAN. The top level directory that log files can be backed up to is the default of /. Connections are not accepted from across the QMI (-Q). The server accepts connections from the hosts named host_name1 and host_name2, and the machine with IP address IP_addr.

  3. Accept connections from both the QMI and the Public LAN

    vcslogserver -d /usr/vcslogs -m host_name1,host_name2,IP_addr -p 1234

    The VCS log server is started and accepts connections from both the public LAN and the QMI. The top level directory that log files can be backed up to is /usr/vcslogs (-d /usr/vcslogs). The server accepts connections from the hosts named host_name1 and host_name2, and the machine with IP address IP_addr. The server listens on the TCP port 1234 (-p 1234) for connections.