Considerations


 

To take full advantage of PL/B in a thin client environment, the programmer should:

 

Note the Following:

  1. The PLBSERVE/PLBCLIENT PL/B program execution is optimized to minimize the network message traffic when possible. As a program is executed, the PLBSERVE runtime detects what instructions can be buffered and what instructions require immediate action. Instructions maybe buffered until either the message buffer is overflowed or until a non-buffered instruction is encountered at which time a single message is sent to the PLBCLIENT task to be processed. This technique provides the best means of minimizing the number of messages sent between the server task and a client.

  2.  

    Any statement that does not return a result or any error will be buffered. These include such statements as:

     

    DISPLAY, SETMODE, WINHIDE, WINSHOW, WINERASE, WINREFRESH, SETWTITLE, ACTIVATE, CHECKITEM, DEACTIVATE, DELETEITEM, DISABLEITEM, DRAGITEM, ENABLEITEM, DESTROY

     

    The following statements are always buffered for all GUI objects except for AUTOMATION, COLLECTION, CONTROL, NETOBJECT, or NETCONROL objects. Buffering is not applied when these statements are used for AUTOMATION, COLLECTION, CONTROL, NETOBJECT, or NETCONROL objects.

     

    EVENTREG, INSERTITEM, and SETITEM

     

    The following statements are always buffered for all GUI objects except for AUTOMATION, COLLECTION, CONTROL, NETOBJECT, or NETCONROL objects. Buffering is not applied when a COLLECTION object is used. However, buffering is used for AUTOMATION, CONTROL, NETOBJECT and NETCONTROL objects only when these statements are grouped together and in this case, these statements can be mixed.

     

    SETPROP, and OBJECT METHODS with no result returned

 

  1. The GETITEM statement is optimized to allow buffering. When multiple GETITEM statements are grouped together, the multiple statements are buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks.

  2. The PLBSERVE runtime is designed to execute most PL/B programs with minimal or possibly no changes. However, PL/B program techniques that appear to work well while using PLBWIN on a single workstation may not provide the best performance for a PLBSERVE/PLBCLIENT. Avoid creating unnecessary objects and preloading object data that may only be used occasionally. Be aware that using PLFORM and FORMLOAD objects can also be more efficient than using individual CREATE operations.

  3. The CREATE statement is optimized to allow buffering. When multiple CREATE statements are grouped together, the multiple statements are buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks. This type of buffering does not occur on the creation for WINDOW, FONT, or COLOR objects.

  4. Be aware that the CONTROL objects are only created and used at the client workstation. Any resources or data required for the control must be available at the client workstation.

  5. If the PLBWIN_ICON={iconfile} keyword is used in the PLBSERVE.INI file, the client main window will use the specified icon. If the {iconfile} name begins with an '!' character, this specifies that the icon file being used must exist on the client.

  6. The PLBSERVE runtime must be installed on a server before it can be used. The number of client connections that can logon to the server is by the authorization number specified during installation. The licensing is by connections and not by users. A single workstation running three plbclient tasks counts as three connections.

  7. The GETPROP statement is only buffered when the SETMODE *SRVBUFMODE keyword is set to a level 2. This mode allows a group of GETPROP statements to be buffered and sent as a single message. The return results are processed to minimize the number of messages sent between the server and client tasks. The SETMODE *SRVBUFMODE=2 works in a one shot manner. Once a user has verified that a group of GETPROP instructions does not have any interactions that can cause unexpected results, a SETMODE *SRVBUFMODE=2 statement can be executed immediately prior to the first GETPROP statement in a group. Once the group of GETPROP statements have been sent to the client, the SETMODE *SRVBUFMODE reverts back to a previous level when a PLB instruction other than a GETPROP is encountered. The user application must execute another SETMODE *SRVBUFMODE=2 when there is another group of GETPROP instructions to be sent as a group.



PL/B Application Server Benefits Client Caching