GUI ScreenIO Client/Server|
GUI ScreenIO Client/Server |
The GUI ScreenIO Client/Server Layer allows you to run most GUI ScreenIO applications, unchanged, as client/server applications over any TCP/IP network (including the Internet).
Your applications look and behave exactly as if they were running locally. In fact, your application is completely unaware that it's running remotely; the GUI ScreenIO Client/Server Layer handles all of the details.
The GUI ScreenIO Client/Server Layer is distributed with GUI ScreenIO as a single user test version so that programmers can test their applications under the client/server.
Client/server applications run on the server, but interact with users (clients) across a network. The client and server may be next to one another on a local area network, or thousands of miles away over the Internet.
When your application (running on the server) calls GUI ScreenIO to display a panel, the GUI ScreenIO server layer sends the panel data across the network to the client, where it is displayed. The client handles all of the interaction with the user; moving from field-to-field, scrolling lists, and so on.
The server is free to process other applications while it waits for a response from the client.
When the user does something that will require the application to do some work, such as pressing a button or selecting a menu item, the client sends the panel's data back to the server. The GUI ScreenIO server layer passes the panel data to the application, the application processes the data, and then, most likely, displays another panel - which will be displayed on the client.
This cycle is repeated until the client is finished with the application.
All of the features of GUI ScreenIO work as expected when you use the Client/Server Layer. That is, your applications will work exactly as they do when running locally.
If you're using a licensed client, or the server side encryption option, all data communications are automatically encrypted using 128-bit RC2 encryption. GUI ScreenIO generates unique, random keys for each connection, and for each job run by a given client, which makes it extremely difficult to eavesdrop on your communications.
GUI ScreenIO's Client/Server Layer also provides authentication services using login IDs and passwords, and can further restrict access to specific IP addresses or specific licensed Client software.
Most of the Windows APIs offered by GUI ScreenIO also work as expected. Some APIs which use external resources, such as PrintFile, PlaySound and ShellExecute, (etc) will transfer the external files from the server to the client as appropriate and then execute the API at the client, which is what you'd want them to do. Still others are Selectable to operate on the Client or the Server - but in all cases will operate correctly on a single machine when NOT running under the Client/Server.
The behavior of the APIs and functions with respect to the Client/Server Layer are documented with the individual APIs and functions.
If your program is calling Microsoft Windows APIs directly, or if you are using COBOL facilities to manipulate files, they will be executed on the server. Therefore, if you're printing a report but not using our print APIs, it would print at the server, not the client.
If you need to print a report at the client, write the report to a file and then use our ShellExecute, or PrintFile APIs to cause it to print at the client.
You should ALWAYS develop your application programs with the awareness that at some time in the future it may be desirable to run them under the client server. Not a great deal of thought need be given to this, other than to ALWAYS use GUI ScreenIO APIs in preference to any APIs provided by your compiler manufacturer where a choice exists. Your compiler manufacture's APIs are not Client Server aware and will only operate on the Server. This may not be appropriate if you intended to print a report or launch a web browser on the client.
Just keep these things in mind while developing your application because the ability to operate under the client/server layer is a selling point for your application and can add significantly to its utility and flexibility. Having a Client/Server aware application can solve significant problems related to growth of an organization when new branch offices are opened but access to the same application and data files is required.
If you suspect that you might want to run your application using client/server there is one small change which you can optionally make to your application that will make it easier: Close and Stop, and Mandatory Shutdown. This change is not absolutely necessary, but it is considered a "best practices" approach not only for client/server, but also for any application in general.
When your application is told by windows to "close and stop" you should handle this situation immediately, in a safe way, from everywhere in your application. This is just good windows programming, and is expected in all windows applications. You may choose to put up an "Are You Sure" screen if work is in process.
The easiest way to do this is to handle it via the GS.COB interface program that we supply. This program should, back out any changes that are in-flight (if necessary) close all files, and stop run.
Windows can instruct our program to close and stop at any time, due to a windows shutdown, a user clicking on the X in the upper right corner of the window, or, in the case of the client/server, if the server loses connection to the remote client.
In this latter case, (loss of connection with remote client) you can see that there would be no opportunity to answer an "Are You Sure" message, however, the server will notify your program with THREE consecutive close-and-stop messages. That way, if your program does put up a "Are you sure" screen, that screen will also get a Close-and-Stop event, (even though no screen was actually sent to the client (because we lost contact).
The server also supports a feature called Inactivity Timeouts. This is an optional feature which allows your applications to be instructed by the server (via Close and Stop events) to shut down after a configurable period of inactivity. If the user starts an application and then walks away leaving that application running it may be desirable to terminate the application after some period, say 30 minutes or an hour of inactivity - no data transmissions to or from the client. This facility is configurable on an application by application basis when running under the Server. If your program ignores Close and Stop events, the server will take the next step, which is the Mandatory Stop.
If your application ignores three consecutive close and stop events while running under the client server layer, your program will get a special event called a Mandatory Stop. Normally this is handled ONLY by GS.COB. (In fact it does not appear in ANY panel copybook and is only defined in GS.COB. As distributed by us, GS.COB simply does a STOP RUN, but you are free to handle this properly (close files etc). This event is handled by GS.COB because that program is compiled by you with your compiler, giving the best chances for a graceful shutdown. If you modify GS.COB in such a way that it ignores the Mandatory stop, your application will be terminated by the server with possible data loss or corruption.
The Mandatory stop will ONLY be sent to your application when running under the client server layer. Further, Timeouts enforced by the server also can trigger Mandatory Stops if Close and Stop events are ignored. We have a White Paper describing the exact working of Mandatory Stops with regard to Timeouts, and job termination by the Server: You can download this white paper by clicking here.
See the Getting started section of the GUI ScreenIO documentation for some hints on this topic.
| © 2000-2019 Norcom, all rights reserved |