sp_cop hung on the failover node.
The problem machine was the failover node in a Veritas cluster. The proddir failed-over correctly, but the library link directory /var/adm/.splex/V-5.3/lib100, which is local to all nodes, contained actual library .so files, not symbolic links to the proddir/lib. In addition, the .so files were for a previous version. Since the statusdb changed for 5.3.4 and an older library was in use, sp_cop could not process the startup statusdb entry and looped forever.
The library problem was corrected by:
1) deleting /var/adm/.splex on the failover node;
2) making a tar volume of /var/adm/.splex on the original cluster node;
3) copying the tar volume to the failover node;
4) restoring the tar volume on the failover node, so the directory /var/adm/.splex/V-5.3/lib100 contained sym links to proddir/lib.
5) then verifying that the proddir/lib .so files were accessible from the sym links, the restarting sp_cop.
When configuring Shareplex within a cluster such as Veritas or HP serviceguard, this method of tarring the /var/adm/.splex directory, copying to the failover, and restoring is the proper configuration mechanism. This procedure is documented somewhere; I'll try to find it.
