once devices are presented to the host and you can see them, if they are on some flavor of unix run this:

symgate define pd /dev/rdsk/c2t0d2s2

where cXtXdXsX represents the native device name ..you can get it by running sympd list -sid 123 (your symmetrix id)

for windows:

symgate define pd \\.\PHYSICALDRIVE39

change PHYSICALDRIVE39 to your physical drive name.

This will make sure that symcli commands are going through the gatekeepers and not any other devices.

We don't run symgate and it works just fine. Just present and mask the gatekeeper devices and they should work.

from what i've read ..if you have regular devices and gatekeepers presented to the box .. by having those specifically defined as gatekeepers it will insure symcli command are not issued using regular devices.

is there specific data being stored on a gatekeeper device? or its just a way of letting symmetrix decide about the authority of the host issuing symcli commands?

It works fine without issuing the symgate.

The purpose of symgate is to specifically allocate gatekeepers to specific device groups. This seems like it might be handy in more convoluted environments where you have device groups competeing for gatekeepers.

you dont't have to assign them to device groups to get higher priority over regular devices.

Use symgate to define a device as a gatekeeper device. This command adds the specified
physical device name to the list of gatekeeper devices.
For example on UNIX, to define device c2t0d2 as a gatekeeper device, enter:
symgate define pd c2t0d2
On Windows, to define device \\.\physicaldrive2 as a gatekeeper, enter:
symgate define pd physicaldrive2
 
SYMCLI uses one of the devices in the list as a gatekeeper, unless you have associated a
gatekeeper explicitly with the device group of the device to which SYMCLI is sending a
control command.

As per my understanding, There are two SCSI commands, Command 3B
(Write Buffer) and 3C (Read Buffer), which are used to r/w to
buffer in the controllers memory.

Now, if GK's being smaller capacity Disk devices on Symms itself,
are not created, then Both the hosts I/O's and these 2 commands
which are used for software communication will hunt for using
the available disk devices to communicate, resulting in the
performance issues.

But with the help of GK, it would be dedicatley used for this
software communication only.

Also one more exception to GK is that, that VCMDB devs are WD by
default, and these 2 scsi cmd has the ability to make them RW enable
first, update the changes and again making then WD.

If using the symgate commands makes you feel better, then there is nothing at all wrong with it.

If you run out of gatekeepers, the SYMCLI will complain and issue errors.

Here is how the Symm selects a GK:

SYMCLI selects a gatekeeper based upon a pre-established priority list. A list of available
gatekeepers can be displayed using the SYMCLI symgate command. The gatekeeper priority
list includes all available physical device names prioritized from most likely gatekeeper to
least likely, as shown below:
1. Defined and associated gatekeepers ¿ These devices have been explicitly designated as
gatekeeper devices and associated with specific device groups.
2. Defined gatekeepers ¿ These devices have been explicitly designated as gatekeeper
devices.
3. Small (< 10 cylinders) non-PowerPath devices, marked by the Symmetrix array with the
inquiry gatekeeper flag.
4. Any small device in the following priority:
¿ PowerPath parent device
¿ PowerPath child device
¿ PowerPath sibling
¿ Count key data format
5. Standard non-RDF and non-meta devices in the following priority:
¿ Non-PowerPath
¿ PowerPath parent device
¿ PowerPath child device
¿ Count key data format
6. RDF R1 devices in the following priority:
¿ Non-PowerPath
¿ PowerPath parent device
¿ PowerPath child device
7. RDF R2 devices in the following priority:
¿ Non-PowerPath
¿ PowerPath parent device
¿ PowerPath child device

More gatekeeper info and how it relates to symcli in the gatekeeper section of the following document:

EMC Solutions Enabler
Symmetrix Array Management CLI
PRODUCT GUIDE
P/N 300-002-939
REV A03