Easy R/W failover for a replicated node

In a ISP environment using the Node Replication feature, the R/O client failover is automated since version 7.1.1 of the ISP server. It works fine, but allows only the restore or retrieve of objects.
If the source server is unavailable for a longer period of time or got finally destroyed it might be necessary to configure the replication target as the active backup server. There might be an urgent request from database admins when log filespaces fill up.
At this time the configuration tasks for R/W access to the target replication server are not that easy and are not automated in any way: the TCPServeraddress parameter has to be updated to point to the right server. Eventually the entries for the former replication server have to be removed. An option might be the redirection of client access by updating the DNS entry if the TCPServeraddress is configured as TCPName rather than the doted address, but this might lead to access problems regarding to the password entries on the client.
This tasks have to be fulfilled on all the clients which have to be redirected - this might end up in hundreds. This is even not an option in environments where portals are used for backup configuration and the backup admin has no access to the option files.
At the time of the R/W failover, the admin has to issue the remove replnode command to break the replication relation between the two nodes on the replication source and target. Another client option could be established, allowing the client to accept the former replication target as backup server. This option would allow dedicated clients to be redirected to the replication target automatically after the remove replnode command was issued manually and processed successfully. The client, which was able to update his option file for the access to the target server, would then be allowed to redirect its backups to the former target. This implementation would also make the failback easier for clients which had R/W access to the target server.

To avoid changes to be made at the server code, this function could be connected to the replmode parameter for the node: if the client on the replication target gets an update from 'syncreceive' to 'syncsend', the client would be allowed to send data to that server. In this case only client code changes are necessary.

The requested function would make a client R/W failover and failback easier and moves this option from a theoretical one to one which could be easily practiced. It also fits in the big picture for the ISP product roadmap regarding to proposed features like metadata replication or continuous replication.