Cross-System Connectivity

As system administrator on the server, you are responsible for assigning a valid server login name to the client who will be accessing the DBEnvironment. That client's login name is then mapped to the server login name in the NETUsers file.

When possible, it is recommended that the client and server login names be the same. This is a precautionary measure to avoid authorization and ownership problems that arise during preprocessing and execution of certain application programs (such as ALLBASE/Query). Such programs make the erroneous assumption that the DBEUserID is based on the client login name. This assumption is true in a local environment, but in a remote environment, the DBEUserID is defined by the server login name specified in the NETUsers file. If the server login name is different from the client login name, you may receive an error message about an invalid authorization or a nonexistent object.

In some cases, such as in HP-UX to MPE/iX connections, it is impossible to have identical client and server login names. In this case, you should make sure that the database administrator is aware of the difference in the client and server login names. (In many cases, you are also the database administrator. If so, see the recommendations below for database administrators.)

As database administrator on the server, you need to be aware that some of your remote client users may have client login names that are mapped to different server login names. In such cases, you might want to take some precautionary measures to avoid problems with ALLBASE/SQL object ownership and authorizations.

One recommendation is to create an authorization group and add the server login name (DBEUserID) to the group. Be sure to grant all the desired authorizations to this group. Give the name of the group to the application users and developers on the remote client. Encourage them to use this group as the ownership qualifier when accessing and creating SQL objects that they own.

If you are an application programmer on the client, you should design your programs so that the data they are accessing can be moved to a remote node without causing changes to the programs. Here are some programming recommendations:

Do not assume that the DBEUserID is based on the client login name. In a remote access configuration using ALLBASE/NET, the DBEUserID is based on the server login name. The server login name need not be the same as the client login name. Therefore, do not fully qualify an unqualified object's owner with the client's login name. For example, if an end user types the command select * from tablename, pass the tablename directly to ALLBASE/SQL without prefixing the table name with the client's login name. ALLBASE/SQL resolves unqualified object owners.

When preprocessing programs remotely, qualify the module owner to be the server login name (DBEUserID) or a group name to which the server login name belongs. This is done by using the -o option in the preprocessor command. For example:

   psqlpas sampledb -i sample.sql -o serverlogin -d

If you are a user of an application program, do not assume that the DBEUserID is based on the client login name. In a remote access configuration using ALLBASE/NET, the DBEUserID is based on the server login name. The server login name need not be the same as the client login name. Therefore, do not fully qualify an unqualified object's owner with the client's login name. Talk to your database administrator about possibly creating a group with your server login as a member. The group can be used to fully qualify ALLBASE/SQL objects.

Some existing programs, such as ALLBASE/Query, may incorrectly assume that the client and server login names are the same. If that is the case, remote access using ALLBASE/NET may have restricted functionality unless the server login name can be made the same as the client login name, or the application is rewritten using the recommendations made above for application programmers.