HP-UX 11.31 I/O stack offers the native MultiPathing feature, which is embedded in the I/O stack.
It is impossible to turn off nMP completely, so that nMP layer is always present in I/O stack in between DMP and SCSI. It does not prevent the DMP from doing the correct multipathing, as VxVM DMP uses nMP API, and sends the I/O requests bound  to specified lunpath.  The I/O from DMP is bound to the specified lunpath, and thus,  nMP does not do any load balancing on it.  

If it is required that only nMP is used on the device, then that device should be configured as a foreign device in VxVM . Using nMP only with VxVM is not recommended, as it restricts the full VxVM capabilities, such as clustering, enclosure based naming schemes, etc.

However, there is often confused with the way VxVM commands report device files on 11.31.
The way device files are reported by VxVM 5.0 commands on 11.31 is controlled with vxddladm(1M).

Here is an example of "vxdisk list" command before and after the change:

# vxdisk list
DEVICE       TYPE            DISK         GROUP        STATUS
c4t0d5       auto:cdsdisk    -            -            online

#vxddladm set namingscheme=osn mode=new

# vxdisk list
DEVICE       TYPE            DISK         GROUP        STATUS
disk19       auto:cdsdisk    -            -            online

The vxddladm(1M) command only changes the way VxVM commands display the device names.
It does not affect the way how DMP sends the I/O requests  to the disk devices.
However, the legacy device names can still be seen in CTD format, when you want to see the paths of the DMP metanode, for example:

# vxdmpadm getsubpaths dmpnodename=disk19
NAME         STATE[A]   PATH-TYPE[M] CTLR-NAME  ENCLR-TYPE   ENCLR-NAME    ATTRS
================================================================================
c4t0d5       ENABLED(A)   -          c4         EMC          EMC0             -
c5t0d5       ENABLED(A)   -          c5         EMC          EMC0             -
 

For VxVM 5.0,use of PFTO is enabled by default in both HP-UX native multipathing devices under VxVM control and DMP devices.

Starting  from HP-UX 11.31, the use of PFTO is disabled by default in the HP-UX native multipathing devices under VxVM control. In case of DMP devices, the use of PFTO is enabled. However, the PFTO settings for both HP-UX native multipathing devices under VxVM control and DMP devices can be changed.

If upgrading from an earlier release (5.0 and prior) to 5.0.1 and above, post-upgrade, the new defaults will be applied to all the devices including the ones for which the PFTO values/states had been previously set. In such cases PFTO state of the given device may change and it will be necessary to explicitly set the state to the desired/pre-upgrade value.

Veritas developed a new functionality in vxpfto(1M) and vxdisk(1M)  commands, which allows the enabling or disablling of the PFTO functionality.
The functionality is available with VxVM 5.0 11.31 RP1 patches (PHKL_38260 PHCO_38235), thus, the system must be patched with RP1 patches or a patch level above.  Additionally, this new functionality requires that the disk group be at a minimum level of 140.

It is strongly recommended that use of PFTO is kept enabled for DMP devices.

 

To enable or disable PFTO on a disk, use the following command:

# vxdisk -g set pftostate={ enabled | disabled }

# vxpfto -g -o pftostate={enabled | disabled}

 

Any PFTO setting currently existing is ignored after disabling the PFTO feature.

Disabling PFTO essentially allows the HP-UX 11.31 I/O stack to perform sufficient retries on I/Os and not prematurely timeout the I/O request.

Enabling PFTO prevents application I/O requests from hanging in the case of non-responding disks and gives the ability to handle I/Os on non-responsive disks.

The pftostate needs to be only set once as the values are persistent across reboots.

The PFTO attribute is at disk level and not at diskgroup level. If the pftostate attribute is set using the "vxpfto" wrapper command,

# vxpfto -g -o pftostate={ enabled | disabled }

then, pftostate will be set for each disk in the diskgroup. However when a new disk is added to the diskgroup, pftostate for this disk will have to be set explicitly and it will not take the pftostate automatically as that of other disks in the diskgroup.