home *** CD-ROM | disk | FTP | other *** search
- quick Example
-
-
-
-
- 1. Environment
-
- This example is designed to be built and executed on a PC
- that runs DOS, the Microsoft C Compiler and utilities, and
- that uses the NetWare network library.
-
-
-
-
- 2. Overview
-
- The Quick Start Manual is the primary guide to building this
- example. Use this README as a supplement to the manual.
-
-
-
-
- 3. Keywords
-
- non-persistent process binding, quick
-
-
-
-
- 4. Files
-
- Source files for this example reside in the following sub-
- directories:
-
- server:
-
- Contains code and build procedures for the server part
- of this distributed application. The server consists
- of the server control procedure, which is provided with
- the product distribution, the dispatcher procedure and
- server stub routines, which are generated by the RPC
- Compiler, and the remote procedures, which are provided
- with this example.
-
- rproc.c remote procedure application code
-
- server.mk makefile for building the server
-
- serv_def.h include file with macro definitions for
- the server control procedure
-
- client:
-
- Contains code and build procedures for the client part
- of this distributed application. The client consists
- of the client main program and any associated routines,
- which are provided with this example, and the client
- stubs, which are generated by the RPC compiler.
-
- client.c client application code (main program)
-
- client.mk makefile for building the client
-
- common:
-
- Contains the RPC interface specification used by the
- RPC compiler to create the client and server stubs.
-
- quick.rpc RPC interface specification for this
- example
-
-
-
-
- 5. Network Configuration
-
- Before you can run this example, you may have to ask your
- system administrator to configure your system specifically
- for your needs. The required configuration is described in
- the file: ..\..\READSPX
-
-
-
-
- 6. Server Name
-
- The macro Server_Name is defined as "example" in the
- distributed code. This name is used in both the client code
- and the server code to identify the server application
- process. In the client code, the variable 'sname' is
- assigned the value of Server_Name (possibly concatenated
- with a hostname, etc.). The variable 'sname' is also used
- in the process binding declaration so that the RPC Compiler
- may generate code that uses the name specified by 'sname' to
- locate the appropriate server application process when a
- remote procedure is called.
-
- There are 2 places in the Quick Start exercise where you
- will use the Server_Name macro. First you are asked to find
- the statements added to client.c. In the second place, you
- will add a define statement for the Server_Name macro to the
- serv_def.h file. In this case, enter
-
- #define Server_Name "example"
-
-
- 7. Building Client & Server
-
- Procedures are included for building the example program.
- These procedures assume that your environment is set up as
- follows:
-
- - The PATH environment variable must specify the location
- of the RPC Compiler executable files.
-
- - The LIB environment variable must specify the location
- of the RPC runtime libraries.
-
- - The INCLUDE environment variable must specify the
- location of the RPC .h include files.
-
- - The PDUDIR environment variable must specify the
- location of the RPC .rpc files.
-
- - The RPCSCP environment variable must specify the
- location of the RPC server control procedures.
-
- The PATH, LIB, and INCLUDE environment variables should be
- set in your autoexec.bat file by modifying their current
- definitions. The PDUDIR and RPCSCP environment variables can
- be set in your autoexec.bat file, or in a local .bat file,
- or directly with the "set" command.
-
- Since a distributed application runs on two machines, you
- must install an executable version of the client or server
- on another machine. If the two machines are identical, you
- can build both executables (the client and server) on one
- machine and then move one of the executables. However, if
- the two machines are not identical, you must follow the
- directions on the other machine for running this example and
- build one of the executable programs there (note that the
- executable filenames may differ across products).
-
- Note that with the Microsoft C Compiler and utilities,
- numerous warnings will be generated when executing the
- makefiles. For example, you may see a "target does not
- exist" or "module not in library" warning. These simply mean
- that the file the makefile is currently creating does not
- yet exist. Generally, all warnings may be ignored.
-
- To build the example program, you simply execute the build
- procedures in each subdirectory as follows:
-
- 1. Change to the client directory (client) and build the
- client:
-
- make client.mk
-
- 2. Change to the server directory (server) and build the
- server:
-
- make server.mk
-
-
-
-
-
- 8. Running the Distributed Application
-
- The server program should be started before the client
- program is run.
-
- To run the example on two machines, proceed as follows:
-
- 1. Change to the server directory (server) on the machine
- running the server and start the server:
-
- server
-
- 2. Change to the client directory (client) on the machine
- running the client and start the client:
-
- client
-
-
-
-
-
- 9. Description
-
- This example is to be used in conjunction with the
- Quickstart Guide. It is provided for the user who wants to
- learn the basic steps required to transform a single-machine
- application into a distributed application that runs on two
- or more networked computers.
-
-
- 10. Problems Completing this Example
-
- If your Quick Start application builds but doesn't give the
- same results as the 'stdalone' application, check that the
- server is running. Because there is no error checking (see
- Standard Error Handling in the Quick Start Manual for how to
- implement error checking), if your client cannot connect to
- the server no error will be reported and the results of this
- example will be returned as zero.
-
- The server may take some time to register. Wait a short
- period and try running your client again.
-
- It is possible that the server failed because someone else
- is running the quick example or another example on the same
- network. All of our examples are built to register with the
- same server name and once that name has been registered, no
- other program may use it.
-
- The solution is simple: change the server name for your
- application to a unique server name. This will prevent two
- or more users from invoking a server process using the same
- server name. Choose a server name not likely to be selected
- by someone else. For example, use your user or login name.
-
- The server name must be changed in both the client and the
- server, and the SAME name must be used.
-
- If you had other problems creating this example, refer to
- another example program called nonper that uses the same
- application. The nonper example basically serves as a
- solution set for the quick example.