Win16 SNA App May Hang Over SNA Win 3.x TCP/IP Sockets Interface

• Microsoft SNA Server, versions 2.0, 2.1, 2.11, 2.11 SP1, 2.11 SP2, 3.0, 3.0 SP1, 3.0 SP2, 3.0 SP3

SUMMARY

A 16-bit Windows application which uses the APPC, CPIC, or LUA interfaces may hang when running over the SNA Server Windows 3.x client TCP/IP sockets interface. This problem can occur on either WFW/Windows 3.x or Windows 95. This problem may only occur when the client is configured for TCP/IP sockets. The application may work correctly when the SNA Server Windows 3.x client is configured to use named pipes or Netware ipx/spx.

There are two main scenarios where this has been observed:

1. If the 16-bit application isn't "peeking" on messages to all windows handles.



2. If the Windows SNA startup call is made from a different windows process than the SNA API calls are made from.

MORE INFORMATION

Normally, a 16-bit Windows application which uses the SNA Server Windows 3.x SNA API's should function properly regardless of the LAN interface used by the underlying SNA Windows 3.x client software. However, the application may encounter problems when running over the SNA client when configured for TCP/IP sockets because the underlying architecture of the socket interface has special requirements for the 16-bit Windows calling application.

If a 16-bit Windows application fails to work on top of the SNA Windows client TCP/IP sockets interface, here are the possible causes.

1. If the 16-bit application isn't "peeking" on messages to all Window handles.
   
   Unlike named pipes and Netware IPX/SPX, the Windows 3.x TCP/IP socket interface runs within the non-preemptive Windows architecture, underneath the calling application. When the SNA Windows 3.x client makes calls to named pipes or Netware IPX/SPX, which run outside of Windows, the network i/o is accomplished with no requirements of the 16-bit Windows application.
   
   However, when the SNA Windows 3.x client is configured for TCP/IP sockets, the 16-bit Windows application must "peek" on messages intended for any Windows handle, in order for the underlying SNA client software to receive data from the TCP/IP sockets interface.
   
   So, in order for the Windows application to work over TCP/IP sockets, the application's Windows message loop should be architected as follows:

   
         /*  get the next message if any */ 
         if ( PeekMessage ( &msg, NULL, 0, 0, PM_NOREMOVE) ) {
            if ( msg.message = WM_QUIT )
               return FALSE;   // let app process WM_QUIT
            PeekMessage ( &msg, NULL, 0, 0, PM_REMOVE) ;
            TranslateMessage (&msg) ;
            DispatchMessage (&msg) ;
        } 

   The second parameter passed to PeekMessage(), the Window handle (hWnd), must be NULL in order for the underlying TCP/IP sockets interface to receive messages on behalf of the application. NOTE: If an API communication layer is being developed (for example, an ODBC/DRDA driver), the developer may not have control over the architecture of the calling application. If this is occurring, then the following strategy can be used to function over TCP/IP sockets:
   
   
   • When SNA client is running over Winsock it makes a hidden window with class name "SNA Winsock". For the other transports, it's "SNA Server".
   
   
   
   • During initialization of the API communication layer, call EnumWindows and find one whose class starts with "SNA ".
   
   
   
   • Establish an SNA blocking hook which dispatches messages only for this window.
   
   
   
   • Call OpenFile (IF_EXIST) on WINSOCK.DLL. If it exists, call
     
     If not, do not call LoadLibrary since this will put a dialog on the screen if it can't find the DLL.
   
   
   
   • Call GetProcAddress for WSAStartup and WSASetBlockingHook, and set a Winsock blocking hook that doesn't dispatch any messages.
   
   
   



2. If the Windows SNA startup call is made from a different windows process than the SNA API calls are made from.
   
   If a Windows application calls the APPC, CPIC or LUA interface, the application should first call WinAPPCStartup, WinCPICStartup, or WinRUIStartup/WinSLIStartup respectively. This startup call should be performed when the Windows process first initializes, before initiating a session over the SNA interface.
   
   A hang has been observed if a Windows 3.x application calls WinAPPCStartup from one Windows process, and then calls the APPC interface from another Windows process. Later versions of the SNA Windows 3.x client software (3.0 and later) now allow a Windows 3.x application to invoke an APPC conversation without first calling WinAPPCStartup. However, the application should still call WinAPPCStartup. If an application calls WinAPPCStartup from one process, and then calls APPC functions from another process, the application may hang if TCP/IP sockets is being used.
   
   To correct this problem, the WinAPPCStartup call should be moved to the process which is actually using the APPC interface, or the WinAPPCStartup and WinAPPCCleanup calls should be removed from the Windows application.

Additional query words:

Keywords : prodsna snaappc snacpic snalua snaprog snawin3x
Version : WINDOWS:2.0,2.1,2.11,2.11 SP1,2.11 SP2,3.0,3.0 SP1,3.0 SP2,3.0 SP3
Platform : WINDOWS
Issue type : kbprb