A machine that is running in the named connection configuration is loaded as a network client that is capable of:
Instructions for loading a machine in the Named Connection configuration can be found here.
This configuration has a combination of facilities not otherwise simultaneously available in DP4 networking
If you mainly want to run programs against one server, or locally, but would sometimes like to run against another server (this might be something as simple as wanting to run against a database held on a handheld device from your PC) this configuration allows you to do so easily without having to stop the DP4 service and load it again in another configuration. You can run a program against another machine simply by specifying the appropriate name with the −server_name servername command tail. Alternatively, applications can use the named connection facilities in DP4 to make their own connections to other machines.
It is possible, with some restrictions, for a server to "call back" a client that is loaded in this configuration, as explained in the next section. It is impossible to do this for a client loaded with the "local resilience" configuration. For details of the callback facility refer to Reverse Connection Facility in the configuration section.
Currently, as, already mentioned, there is no support for distributed transactions. This is most significant limitation of the system compared with Multiple Resilience, and it will be removed in a future release of DP4. If your system does not require distributed transactions and is currently using AUXDISTR you should consider updating your system to use Named Server Configuration instead, as it will probably give improved performance.
The Named Connection configuration is only supported for TCP/IP protocol and only on Win32 and Unix like platforms.
Prior to 4.621 if you use the -rocopy or -nocopy command tails on TCPMGR you will also be prevented from running programs that use DP4 sf_() functions (this includes most of the database backup/restore/maintenance utilities) locally. This restriction is removed in 4.621, because local connections are rerouted to bypass TCPMGR.
There are no special facilities for error handling in this configuration. Resilient Programs that are specifically written for this configuration must take control of error handling rather than relying on the default sys_error() and sys_fail() behaviour of DP4. When a network error occurs an application must close the affected connection, but can try to reopen it afterwards if desired.