Windows Client/Disk-Server Configurations

Note: The information in this document is generally obsolete and is only presented here for archive purposes.

This document explains how to set up an APPX for Windows Client/Disk-Server configuration. This is known a "Distributed Client/Server".

"Server" in this discussion is a Disk Server, which serves up a separately-lettered shared disk drive. This drive may be shared using NT, Novell, or some other disk-sharing facility.

For network-performance and data-integrity reasons, you may want to strongly consider APPX Presentation Client/Server. Under Presentation Client/Server, the APPX engine resides on a Unix or NT server, next to the data on which it operates, minimizing network traffic. A "thin" Presentation Client is responsible only for GUI Terminal issues (Keyboard, Screen, Mouse), and can run over a local LAN, a WAN, or the internet. Both Windows and Java Clients are available. The Java Client can run either standalone or thru a browser. Also, if you are using Win9x workstations to run APPX, and you are NOT running Presentation Client/Server, you risk corrupting your server data due to bugs in Win9x's Windows File Sharing. (This is a Microsoft Windows issue affecting all shared-disk database configurations with Win9x clients, not just APPX, and MS has provided techniques to minimize BUT NOT ELIMINATE the possibility of problems, so we now recommend that customers skip this configuration and use Presentation Client/Server instead. However, if that's not possible for you and you're willing to accept the risk of potential data integrity issues for which we cannot be held responsible, setup information for this configuration is below.)

How do you set up the links between client and the server, if the APPX engine is on every client, yet 0SA is on the SERVER? How do you make sure you will point to the server when necessary?

First, assume that you have two machines: one named 'Client' and the other named 'Server'. Server will be where you want most of the shared files to exist and Client is probably a Windows PC networked to Server somehow.

The Client must be able to access data on the server through a regular drive letter. For example, Server may export its D: drive to Client. Client might be able to access \\server\D: as drive R:

To tell Client to look at Server for it's System Administration files, set the following environment variable on Client:

set APPX_0SA_PATH=R:\APPX\data

(Be careful not to set this equal to R:\APPX\data\0SA ... APPX will want to provide the ".\0SA" itself.)

To tell Client to store the design files for an application on Server, but put any executable modules on a local drive (for performance), define an FMS group as follows:

FMS Path: R:\APPX\data
FMS Controls: EM=C:\APPX\local_data

(If you don't specify an 'EM' FMS Control, your Application's EMs will be stored on the R: drive along with the rest of Application Design, increasing network traffic.)

Assign the application to this new FMS group. APPX will then look for the design files in R:\APPX\data\*, and put the executable modules in C:\APPX\local_data.

Leave APPXPATH defined to its normal location on your client PC. This will allow APPX to load locally, minimizing your network traffic load.

Finally, you will need to use FMS Groups to point your Enduser Database toward the starting point of your Database tree on your R: Server.

Under this scenario, your Disk-Server ( R:) contains:

1. Your Application Design "Source" code,
2. Your "0SA" System Administration files, and
3. Your shared Enduser Data

1. Your APPX engine (appx.exe),
2. APPX EMs (./data/00/0*/), and
3. Application Design EMs (your "Object" code, or "P-code")

If you want your server to also be a client (such as in a Peer-to-Peer network) (where, as a client, APPX is located on the 'C:' drive, and there exists no 'R:' drive), you can use the DOS "subst" command to create a drive 'R:' on your Server, synonymous with 'D:' on the same server.

For example:

subst R: D:

or

subst R: D:\APPX\Data

Performance Guidelines:

As with any networked solution, the performance of the Application will be a function of the bandwidth and performance of the network on which it operates. The above configuration is optimal and minimizes network traffic for user-interactive shared application situations.

For situations where there is much disk IO (for example Postings or large reports), the above configuration requires a record to come over the network from the Server to the APPX engine resident on the Client for every record read from the server. It also requires a record to be pushed over the network, for every record written or rewritten by the engine resident on the Client. If you elect to do large posts over a network using this technique, you will want to be sure your network is up to the task.

Under this scenario, you would want to perform:

• Operator-interactive processes (such as data entry / file maintenance) upon your Distributed APPX engine resident on the Client, and ...
• Disk-intensive processes (such as batch posts and reports requiring heavy Disk IO) upon a copy of an APPX engine running on the same CPU as the data upon which it operates, so that the engine is closest to (has high bandwidth to) the data upon which it will operate.

Comments:

Read what other users have said about this page or add your own comments.

-- ChrisBrower - 2011-06-08