ICP GDTMON User manual


&KDSWHU.'LDJQRVLV3URJUDP*'7021
&KDSWHU.
7KH
'LDJQRVLV3URJUDP
*'7021


&KDSWHU.*'78VHUV0DQXDO
.7KH'LDJQRVLV3URJUDP*'7021
GDTMON (GDT monitor) is a helpful and flexible diagnosis tool for the monitoring, mainte-
nance and tuning of mass storage subsystems which are based on one or more ICP Con-
trollers. The key features of GDTMON:
Diagnosis program with a graphical user interface. Clear performance representation
with variable horizontal bars
Available under MS-DOS, NetWare 3.x & 4.x, Windows 95, Windows NT, OS/2 and
SCO UNIX
Loadable locally (on the server) or remotely from an authorized workstation (NCPE
and NETBIOS protocol support)
Indicates the performance, expressed in [KB/sec] and [IO/sec], of:
- Host Drives (Disk, Chain, RAID 0, 1, 4, 5, 10)
- Logical Drives
- SCSI Drives
Indicates the GDT cache utilization
- Read-Hits
- Write-Hits
- Separate indication for data- and parity-cache (RAID 4/5 )
Allows online changing of the GDT cache parameters:
- Cache ON/OFF
- Delayed Write ON/OFF
Allows online changing of the SCSI devices’ parameters:
- SCSI protocol
- Synchronous or Asynchronous data transfer
- Setting of the synchronous data transfer rate
- Disconnect/Reconnect
- Disk Cache ON/OFF
- Tagged Queues ON/OFF
Indicates the structure of Logical, Array and Host Drives
Performs online parity checking of RAID 4 and RAID 5 Host Drives
Allows the online RAID Level migration and capacity expansion of existing Array
Drives
Saves all relevant configuration data to floppy disk or hard disk
Sets up or removes RAID 1 Disk Arrays while maintaining full operational conditions
Performs Hot Plugs on RAID 4 / RAID 5 disk arrays
Allows to add or remove a dedicated or pool Hot Fix drive while maintaining full op-
erational conditions


&KDSWHU.'LDJQRVLV3URJUDP*'7021
./RDGLQJ*'7021
As mentioned before, the GDTMON program is available for various operating systems.
It can be used either locally or remotely. This means that all ICP Controllers in a network
can be monitored and serviced from one (or several) workstation(s). The communication
between the ICP Controller(s) and the GDTMON program is based on the NETBIOS or NCPE
protocols. Thus, for example, it is possible to monitor the ICP Controller in an OS/2 work-
station or the ICP Controller in the Novell NetWare fileserver from a Windows 95 worksta-
tion.
In order to be able to access a certain computer system with its ICP Controller remotely on
the network, a special communication module has to be loaded first, which routes the in-
formation through the network. For a Novell NetWare fileserver this is the CTRLSRV.NLM
module (NCPE). For Windows NT (server and workstation), Windows 95 and OS/2 (server
and workstation) this is the NBSERVx.EXE module (NETBIOS). While the module is loaded
it searches for a CTRLSRV.CFG (Novell NetWare) or NBSERV.CFG (Windows NT, Windows
95 and OS/2) file, which includes the definition of the access rights of the different users
and their passwords. The CFG file assigns every user to two different access levels. Access
level 0 gives the user all functions to view and change the controller-, disk-drive and disk-
array-settings. Access level 1 entitles the user only to view the various settings and per-
formance data.
The Windows NT, Windows 95 and OS/2 driver diskettes include so-called DLLs for the sup-
ported protocols. Example: If the MON4NETB.DLL file is located in the same directory as
GDTMON.EXE file for Windows NT, the NETBIOS protocol is automatically used for the
GDTMON on this system. As soon as the NETBIOS support of this operating system is in-
stalled during the network configuration, the GDTMON on this system can communicate
through this protocol with another system in the network which has a ICP Controller.
The following drivers for the ‘remote’ GDTMONitor are currently available:
OS/2
GDTMON32.EXE GDTMONitor for OS/2
MON2NETB.DLL NETBIOS DLL for OS/2
MON2NCPE.DLL NCPE DLL for OS/2
NBSRV2.EXE NETBIOS Server for OS/2
NBSRV.CFG Configuration file for NetBios Server
NBCLEAN2.EXE NETBIOS analysis program
Windows NT
GDTMON.EXE GDTMONitor for Windows NT
MON4NETB.DLL NETBIOS DLL for Windows NT
NBSRV4.EXE NETBIOS Server for Windows NT
NBSRV.CFG Configuration file for NETBIOS Server
NBCLEAN4.EXE NETBIOS analysis program
Windows 95
GDTMON.EXE GDTMONitor for Windows 95
MON5NETB.DLL NETBIOS DLL for Windows 95
NBSRV5.EXE NETBIOS Server for Windows 95
NBSRV.CFG Configuration file for NETBIOS Server
NBCLEAN5.EXE NETBIOS analysis program
The MS-DOS GDTMON also allows remote access. The DLLs are integrated into the GDT-
MON.EXE file, thus there is no NETBIOS server available for MS-DOS. Since there is no
NETBIOS support within MS-DOS, it is necessary to load the NETBIOS program to access
from a MS-DOS workstation through the network a ICP Controller in a Windows NT and


&KDSWHU.*'78VHUV0DQXDO
OS/2 workstation or server, or a Windows 95 workstation. NETBIOS is part of the Novell
NetWare operating system. For the remote access of a Novell NetWare fileserver the
NETBIOS program is not needed.
..//RRDDGGLLQQJJWWKKHH**''7700221133UURRJJUUDDPP88QQGGHHUU11HHWW::DDUUHH
The GDTMON program for NetWare is part of the GDT Novell NetWare disk.
GDTMON can be used either under NetWare 3.1x or under NetWare 4.0x. There are two dif-
ferent methods of loading GDTMON:
- loading GDTMON on the fileserver
- loading GDTMON on an authorized workstation (remote)
Loading GDTMON on the fileserver. Beforehand, the GDT NetWare driver (GDTRP311.DSK
for NetWare 3.11, GDTRP312.DSK for NetWare 3.12 and GDTRP400.DSK for NetWare 4.x)
and the auto-loading module CTRLTRAN.DSK must have been loaded on the fileserver.
LOAD GDTMON <ENTER>
on the fileserver.
Loading GDTMON on a workstation. In this case, too, the GDT NetWare driver and the
auto-loading module CTRLTRAN.DSK must have been previously loaded on the fileserver
console. In addition, the module CTRLSRV.NLM has to be loaded. This module searches for
a file named CTRLSRV.CFG. This file must be located in the same directory as
CTRLSRV.NLM. The system administrator has to set up a user group named
GDT_OPERATOR. All users belonging to this group are given access (through GDTMON) to
the ICP Controller(s) in this specific fileserver (Access level 0). Now, the GDTMON program
can be loaded from one (or more) workstation(s):
GDTMON <ENTER>
By selecting the menu Select Controller of the GDTMON main menu, you can now choose ei-
ther a fileserver (equipped with a ICP Controller), or a ICP Controller in your workstation.
..//RRDDGGLLQQJJWWKKHH**''7700221133UURRJJUUDDPP88QQGGHHUU2266
The GDTMON program for OS/2 is part of the GDT OS/2 disk. To load the program under
OS/2, enter:
GDTMON32 <ENTER>
..//RRDDGGLLQQJJWWKKHH**''7700221133UURRJJUUDDPP88QQGGHHUU::LLQQGGRRZZVV1177
The GDTMON program for Windows NT is part of the GDT Windows NT disk. To load the pro-
gram under Windows NT, enter:
GDTMON <ENTER>
..//RRDDGGLLQQJJWWKKHH**''7700221133UURRJJUUDDPP88QQGGHHUU::LLQQGGRRZZVV
The GDTMON program for Windows 95 is part of the GDT Windows 95 disk. To load the pro-
gram under Windows 95, enter:


&KDSWHU.'LDJQRVLV3URJUDP*'7021
GDTMON <ENTER>
..//RRDDGGLLQQJJJJGGWWPPRRQQXXQQGGHHUU66&&228811,,;;
In order to be able to use the gdtmon program under SCO UNIX (2.x, 4.x and 5.x), it be-
comes necessary to substitute the standard terminal entry by a new one:
cd /usr/lib/terminfo <ENTER>
tic gdt386.src <ENTER>
Before each loading of gdtmon, this terminal has to be activated by:
TERM = gdt386 <ENTER>
export TERM <ENTER>
These two lines can also be inserted in the .profile file and will then be automatically proc-
essed during each login. The gdtmon program itself is copied during the SCO UNIX installa-
tion (chapter G of this User's Manual) into the /etc directory. gdtmon is loaded by entering:
gdtmon <ENTER>
.7KH*'70213URJUDP
As mentioned before, the GDTMON program appears identical for all operating systems, so
we can demonstrate the use and functioning of this program regardless of the operating
system used. In previous chapters we have already described the hierarchical structure of
the GDT firmware. We have defined 4 different levels of hierarchy: Level 1 where the physi-
cal SCSI drives named Physical Drives are found, level 2 containing the Logical Drives
(made up of one or several Physical Drives), level 3 where we have the Array Drives, and fi-
nally, level 4 where the Host Drives are. Only the latter ones are known to the operating sys-
tem. The drive of a given level of hierarchy is always set up by using the drives of the next
lower level as components. Accordingly, GDTMON has various menu options, each referring
to one level of hierarchy
+RVW'ULYHV Level 4
/RJLFDO'ULYHV Level 2
3K\VLFDO'ULYHV Level 1
Each menu option displays the performance of the drives belonging to the corresponding
level. (Note: The performance of Array Drives and Host Drives is identical). The performance
is measured in KB/s (kilobyte per second, transfer rate) and IO/s (I/Os per second, number
of simultaneously processed I/Os on the ICP Controller). The performance is displayed nu-
merically as well as graphically in the form of variable horizontal bars, with separate indica-
tions for each drive and its write and read accesses.
..66HHOOHHFFWW&&RRQQWWUURROOOOHHUU
This menu option yields a list of available ICP Controllers. By selecting a protocol, you have
either access to the ICP Controller(s) in your local computer (e.g., MS-DOS, Windows NT,
Windows 95 or OS/2 protocol), or to a ICP Controller in another computer (server or work-
station) in the network (NetWare NCPE or IBM NETBIOS protocol). All diagnosis and main-
tenance functions of GDTMON refer to the ICP Controller you have selected here (and the
SCSI devices connected with this controller).


&KDSWHU.*'78VHUV0DQXDO
(MS-DOS) in the Select Protocol menu indicates that the GDTMON program was loaded on
a MS-DOS computer. I.e.: If GDTMON had been loaded under Windows NT, we would see
there (Windows NT).


&KDSWHU.'LDJQRVLV3URJUDP*'7021
..++RRVVWW''UULLYYHHVV
This menu option leads to the list of available Host Drives (level 4). We would like to recall
that the operating system (e.g., NetWare) only recognizes these Host Drives and not their
possibly complex structures. This means that it is of no importance for the operating sys-
tem if a Host Drive consists of one single SCSI drive (of the type disk), or of 5 SCSI drives
configured to form a RAID 4 Array Drive. Apart from the performance, the name, type, state
and capacity (1024KB = 1MB) of a Host Drive is displayed. The figures shown at Total repre-
sent the overall performance of the Host Drives as a whole. With the mand okeys you
may change the scale of the graphical KB/s indication. With the nand pkeys you can scroll
the screen to see further Host Drives (if available).


&KDSWHU.*'78VHUV0DQXDO
(Note: All Host Drives on the screen shown above are idle.)
..//RRJJLLFFDDOO''UULLYYHHVV
This menu option yields a list of available Logical Drives (level 2). Logical Drives are the
components for Array Drives and Host Drives. In its most simple form, a Host Drive consists
of one Logical Drive which is made up of a single SCSI drive (type disk). In case of RAID Host


&KDSWHU.'LDJQRVLV3URJUDP*'7021
Drives, the performance of the Logical Drives forming a RAID Host Drive are shown in the
menu Logical Drives. The performance data displayed here gives immediate information on
the quality of a given Host Drive. When judging the indicated performance of Logical Drives
belonging to a RAID Host Drive, the following considerations should be taken into account:
(a) RAID 0, RAID 1, RAID 10 and RAID 5 Host Drives
If a certain Logical Drive shows poor performance for a longer period (when compared to
the other Logical Drives), this Logical Drive impairs the overall performance, making it the
bottle neck of the entire RAID Host Drive.
(b) RAID 4 Host Drives
In principle, the same as in (a) applies to RAID 4 Host Drives, with the exception made for
the parity Logical Drive. The poor performance can have various reasons: the SCSI drive
forming the Logical Drive
is too slow (different from the other SCSI drives with regard to type or manufacturer)
has wrong parameters (SCSI II, disk cache, tagged queues etc.)
has too many defects, causing the read/write actuator to have to move to alternate tracks
very often
When setting up RAID 4/5 Host Drives, please observe the notes on RAID 4/5 Host Drives
exposed in the chapter GDTSETUP in Detail.


&KDSWHU.*'78VHUV0DQXDO
The figures under Total represent the total performance of all Logical Drives. With the mand
okeys you may change the scale of the graphical KB/s indication. With the nand pkeys
you can scroll the screen to see more Logical Drives (if available).
..33KK\\VVLLFFDDOO''UULLYYHHVV
In addition to the performance report on the SCSI drives, you are given additional informa-
tion on each device:


&KDSWHU.'LDJQRVLV3URJUDP*'7021
the GDT SCSI channel the SCSI drive is connected to
which SCSI-ID the drive has
the name of the SCSI drive
the gross capacity (1MB = 1024KB)
The Retries/Reassigns counters have a particular meaning:
(1) The Retries counter is incremented by one unit whenever the ICP Controller retries to ac-
cess a SCSI device. If this counter continues to increase (possibly on other SCSI drives, too)
it is very likely that the SCSI cable is not good enough for the selected data transfer rate (ca-
ble too long, poor quality of cable and connectors), or that the SCSI bus is not properly
terminated (too many terminators on the cable, or missing terminator). In very few cases is
the SCSI drive concerned defective. The retry counter also increases when the SCSI parame-
ters of a SCSI drive are changed (see further ahead). Obviously, retries due to this do not
imply bad SCSI cabling.
(2) The reassign counter reflects the number of media defects which occur on the SCSI
drive. Defective blocks of the SCSI device are assigned substitute blocks (spare blocks)
which are either on the same track, or on alternate ones if all spare blocks on the same track
are already in use. The administration of the reassignments is carried out by the SCSI drive
through according reassignment tables. Note: If a SCSI drive works with alternate tracks, it
is generally no longer suitable for applications with high performance expectations. When-
ever a defective block is being accessed, the read/write actuator has to move to an alternate
position and this requires extra time.
If you observe that the number of reassigns is constantly increasing, you may suspect that
something is wrong with this drive.
With the mand okeys, you can change the scale of the graphical KB/s indication.
With the nand pkeys, you can scroll the screen to see more SCSI drives (if available).


&KDSWHU.*'78VHUV0DQXDO
..&&DDFFKKHH66WWDDWWLLVVWWLLFFVV
This menu option gives information on the utilization of the GDT cache. For RAID 4/5 Host
Drives, the data cache and parity cache are displayed separately.
Note: The GDT firmware only allocates cache RAM to the GDT parity cache if RAID4/5 Host
Drives have been set up.


&KDSWHU.'LDJQRVLV3URJUDP*'7021
..66DDPPSSOLOLQQJJ55DDWWHH
By setting the sampling rate, you can choose the interval at which the ICP Controller deliv-
ers new measurements. According to the operating system used, the sampling rate can be
set to a maximum of 60 seconds. The default setting is 1 second.


&KDSWHU.*'78VHUV0DQXDO
.7KH0HQX9LHZ&KDQJH6HWWLQJV
This menu includes a set of very powerful options and functions for the online maintenance
and diagnosis of RAID 1/4/5/10 Host Drives.
From this menu you can select further submenus:
&RQWUROOHU - View the ICP Controller configuration
- View Last Events
- View/Change the Intelligent Fault Bus settings
&DFKH6HWWLQJV - View/Change the GDT cache parameters
3K\VLFDO'ULYHV - View/Change the SCSI parameters
/RJLFDO'ULYHV - Display the structure of Logical Drives
- Add/Remove Mirror Drives to/from Host Drives
- Perform a Hot Plug on a RAID 1 Host Drive
- Add/Remove Private Hot Fix and Pool Hot Fix drives to/from a
RAID 1 Host Drive
$UUD\'ULYHV - Display the structure of RAID 4/5/10 Host Drives
- Perform a Parity Verify on RAID 4/5 Host Drives
- Perform a Parity Recalculation on RAID 4/5 Host Drives
- Perfrom online capacity expansion and/or RAID level migration
- Perform a Hot Plug on RAID 4/5/10 Host Drives
- Add/Remove Private Hot Fix and Pool Hot Fix drives to/from
RAID 4/5/10 Host Drives
6DYH,QIRUPDWLRQ - Save all relevant configuration data to disk


&KDSWHU.'LDJQRVLV3URJUDP*'7021
Before going into detail, some information on the so-called Hot Plug of fault tolerant disk
arrays (RAID 1/4/5/10) is given below.
..11RRWWHHVVDDQQGG,,QQIIRRUUPPDDWWLLRRQQRRQQWWKKHH++RRWW33OOXXJJIIXXQQFFWWLLRRQQRRII**''77002211
Fault tolerant means that a hard disk which is part of a RAID 1/4/5/10 Array Drive can fail
without causing data loss on the Array Drive. At the same time, the Array Drive remains fully
accessible. Obviously, the Array Drive then lacks the redundant data, therefore the defective
disk should be replaced by an intact one as soon as possible. In chapters C (RAIDYNE
Quick-Setup) and L (GDTSETUP in Detail), we have shown with various examples how to ex-
change a defective drive with GDTSETUP. Moreover, we described the functioning of the so-
called Hot Fix drive. This "constantly available spare part when needed" automatically inte-
grates itself into the Array Drive and is therefore the quickest means of regaining a redun-
dant Array Drive.
The Hot Plug function enables the replacement of a drive of an Array Drive (either in the
ready or fail state) while the system continues to run, that is, without having to shut down
the NetWare fileserver for instance. A drive replacement may not only become necessary
when the drive has already failed, but also when there are signs that a failure could occur
soon (strong whistling of the hard disk, or constant retries of the read/write head).
Only those users with thorough knowledge of RAID and the ICP Controller should use the
Hot Plug function. Improper use can lead to data loss. (Naturally, we have integrated all
kinds of security provisions into the ICP Controller and GDTMON. But how can we prevent a
user from plugging out the wrong drive?). We recommend that you document each Array
Drive immediately after its configuration with GDTSETUP. This record should at least com-
prise the following information:
To which ICP Controller has the Array Drive been connected ?
Which SCSI devices (hard disks) are part of the Array Drive ?
To which SCSI ID have they been set ?
Which SCSI devices terminate a SCSI channel ?
In addition, the SCSI devices themselves should be labeled with the above information. The
following is an example of such a label.
&[\]W
&: controller number [: SCSI channel
\: SCSI-ID ]: Logical Drive number
W: = terminated, = not terminated
Example:
%
controller number 1, SCSI channel B, SCSI-ID 6, Logical Drive number 3, terminated. The
menu option Save Information of GDTSETUP, GDTMON program can be of help when setting
up the documentation.
How does the Hot Plug mechanism work ?
During the Hot Plug, the SCSI channel of the ICP Controller to which the drive to be ex-
changed is connected, is temporarily "halted" (for the time needed for the exchange), so
that the drive can be disconnected from the SCSI bus and replaced without any risk. After
the replacement, the SCSI channel halt is lifted and the firmware automatically begins to


&KDSWHU.*'78VHUV0DQXDO
rebuild the new drive. The halting and the halt-lifting of the GDT SCSI channel is controlled
by the Hot Plug function. The above mentioned halting of the SCSI channel avoids that in-
terferences caused by plugging off the drive impair the functioning of other drives still ac-
tive on this SCSI channel. Moreover it prevents the possible destruction of the SCSI
processors of the ICP Controller or the SCSI protocol ICs of the SCSI drives. However, this
implies that none of the SCSI devices of the halted SCSI channel can be accessed during
the time the defective drive is being exchanged. This may affect, for example, other drives of
this Array Drive, other Array Drives, simple Host Drives (of the type disk etc.), and Not Direct
Access Devices (CD-ROMs, DAT streamers, MOs, etc.). If the ICP Controller has only one SCSI
channel, or if all SCSI devices are connected to one single SCSI channel, then no SCSI de-
vice can be accessed during the time of replacement. Therefore, it is evident that it is best if
the ICP Controller had as many SCSI channels as possible and that all SCSI devices were
distributed equally to the available channels in order to avoid that the Array Drive or other
SCSI devices cannot be accessed during the Hot Plug drive replacement. This non-
accessibility of the Array Drive during the replacement is communicated to the operating
system by the GDT driver program that integrated the ICP Controller into the operating sys-
tem. If the period of non-accessibility becomes too long a system error may occur. The Hot
Plug should be carried out as quick as possible.
Various manufacturers offer so-called Disk Shuttle (sometimes also called Disk Shelf) subsys-
tems. There are two categories of these subsystems: Non-Intelligent and Intelligent. Both
generally consist of the shuttle itself, a shock safe metal or plastic enclosure containing the
hard disk, a frame which is mounted in the computer case or in an external subsystem, and
a sufficient cooling system.
Especially the last component is very important. If the hard disks run too hot, it is very likely
that they will fail. In addition, their lifetime is reduced dramatically. The mounting frame
has appropriate slide rails and locks that fit with the shuttle. The shuttle can be slid into or
out of the mounting. When using any of these systems you have to make sure that the SCSI
termination (regardless of whether the drive has been terminated or not) is made in the
mounting frame. In addition, always use high quality connectors for the SCSI buses and the
power supply. It is very important that during the plug out, the SCSI bus is disconnected
first, and then the power supply. When plugging in again, the order is vice versa.
The Non-Intelligent subsystems have no communication with the ICP Controller and no in-
telligent backplane (i.e., with sensors).
If it is intended to avoid this halting and halt-lifting of the GDT SCSI channel, an Intelligent
subsystem is needed. The ICP Controllers support two different types of such subsystems:
SAF-TE and DEC(TM) fault bus compliant subsystems. SAF-TE stands for SCSI Accessed Fault-
Tolerant Enclosure and is soon becoming part of the SCSI specification. The DEC(TM) fault
bus is a special technology from Digital Equipment (TM).
With these subsystems, the ICP Controller enables the performance of the so-called Auto
Hot Plug, which reduces the whole Hot Plug procedure to the simple replacement of the disk
shuttle which contains the desired hard disk. Furthermore, these subsystems have typically
several LEDs to indicate for example the disk shuttle which contains the defective hard disk.
..&&RRQQWWUURROOOOHHUU
This option displays details on the ICP Controller. For example, how much Cache RAM the
ICP Controller has and what the current termination setting of the various SCSI channels is.


&KDSWHU.'LDJQRVLV3URJUDP*'7021
Press <F3> to get detailed information on the configuration of the Intelligent Fault Bus
(IFB). Changing and enabling these features requires the existence of an IFB-compatible
subsystem.


&KDSWHU.*'78VHUV0DQXDO
..&&DDFFKKHH66HHWWWWLLQQJJVV
This submenu displays the current GDT cache settings which can be changed here. The
various settings are:
&DFKH21 the GDT cache is enabled, that is, all accesses to the Host
Drives pass through the GDT cache
&DFKH2)) the GDT cache is disabled
'HOD\HG:ULWH21 Write accesses are delayed, i.e., the write-back cache algorithm
is active
'HOD\HG:ULWH2)) All write accesses are directly transmitted to the Host Drives. If
delayed-write is off and the Cache is ON, the GDT cache works
exclusively as a read cache.
Note: Best performance is achieved with Cache ON and Delayed Write ON.
..33KK\\VVLLFFDDOO''UULLYYHHVV
This option gives a list of all direct access SCSI devices connected to the ICP Controller. Be-
sides information on the GDT SCSI channel, the SCSI-ID, the name/vendor and the gross
capacity (1MB = 1024KB), it also shows which SCSI device(s) belong to a given Logical
Drive.
When you select a SCSI device in this list and then press <ENTER>, GDTMON gives you
further information on the Drive Settings of this SCSI device. These settings may be changed.
The Last Status information should always be 0x00000000. After a device failure or other
significant events, a different value may be displayed here. Chapter L.7.4 of this manual


&KDSWHU.'LDJQRVLV3URJUDP*'7021
gives an excerpt of the SCSI specification with all relevant device Last Status information.
This information may be of assistance in further analysis of the problem.
The Grown Defects counter shows the number of media defects which have occurred since
the first time the device was operated with a ICP Controller. A specific SCSI hard disk is in a
good condition when it has 0 grown defects. When this counter increases, there is definitely
something wrong with the device.


&KDSWHU.*'78VHUV0DQXDO
If you select the SEP of a SAF-TE subsystem, GDTMON displays a list of the installed and
configured slots in the subsystem
Press <F2> to get the status of the SAF-TE enclosure.