Debugging Windows Server functions
|Date:||4 November 2002|
|Product/Release:||Visual LANSA V9.1|
|Abstract:||How to debug Windows server side functions that are executed by the CallServerFunction BIF|
|Submitted By:||LANSA Technical Support|
This tip explains how to debug a function that exists on a Windows server and is being executed from a client application. The server function in question is invoked by the client application using the built-in function (BIF) ‘CALL_SERVER_FUNCTION'. This example utilises a process called ‘PCXDEMO3' which can be found in the DEM partition.
The example results in an application with the following features and behaviour:
- A Visual LANSA install (server version with the LANSA Listener running) on a Windows backend
- A Visual LANSA client application running on Windows
- The client application makes a connection with the server, and then executes a server side function and receives data back from the server side function
- When stepping through the client application in debug, the debug processing will pause at the ‘CALL_SERVER_FUNCTION'. A debug window will then appear on the server, providing the functionality to step through the server side function in debug mode. Once the server side function has been stepped through, focus will go back to the client side application.
- Note: There is no need to have the LANSA development environment open on the server machine. A debug window will be invoked regardless.
How to setup this example
This example is intended for Windows environments
- Install a server version of Visual LANSA on the Windows server.
- Install a version of Visual LANSA on the client machine or run the LANSA form/function in debug mode on the Client (must be compiled with debug enabled).
- On the server machine ensure that the process named ‘PCXDEMO3' and all of its related functions are compiled with debug enabled (the demonstration system is shipped with debug enabled).
- Do the same on the client machine (Note: It is possible to have the same machine acting as the both the client and the server but is not recommended to avoid confusing the test).
- Start the listener on the server. To do this, go to Start, LANSA, Settings and Administration, LANSA Communications Administrator. In the resulting Window select ‘Advanced' then ‘Listener' and then ‘ Start Listener'.
- Now on the client run the process ‘PCXDEMO3'. In the list of parameters you can elect to debug the client side application or not. Example screen below.
- When you run the process the resulting screen will appear:
You now need to define the server that you wish to connect to. In order to do this, click ‘Server' at the top of the screen. Then click ‘Define' from the drop down.
- The resulting screen (shown below) will allow you define the server and pass the necessary parameter to the server so that the debug will be invoked on the client side.
Note: If implementing this functionality in an application other than this example, you may need to include the above X_RUN overrides to the X_LANSA.PRO.
- Enter the above X_RUN Overrides, replacing the values with value that relate to your site. Note: Notice the last parameter ‘DBUG=Y'. This parameter is the parameter that tells the server to invoke the debug on the server side.
- Now save and close this window and select ‘Connect' from the ‘Server' drop down on the main window. You will be prompted for a user name and password.
- Once the connection has been established click the button ‘RPC1' from the process main window. This will result in the following screen:
- Simply enter 2 numbers to add and select ‘Perform on Server' and click enter.
If you have elected to debug the client side application in addition to the server side application, the debug window will open on the client machine. The debug step though will eventually stop at the ‘CALL_SERVER_FUNCTION' BIF. The client side application will appear to pause at this point. A debug window will open on the server. If the function on the server has been compiled with the ‘Debug' option selected, the function will be ready for debugging and can be stepped through. Once the debug window on the server is finished, it will close and the client application will resume.