AUGUST 1993 VOLUME 5 NUMBER 8

INDEX

• MAD'S COLUMN
• ARTICLES
• DEVELOPER NEWS
• TECHNICAL INSIGHTS
• NIBBLES AND BITS
• DEVELOPER EDUCATION
• CURRENT PATCHES FOR NOVELL DEVELOPMENT TOOLS
• CONTACTING NOVELL
• ERRATA
• ACKNOWLEDGMENTS

MAD'S COLUMN

Hello and welcome to the August 1993 issue of Bullets!

It has taken us several months to assess and devise one complete all-encompassing forum where any Novell developer can post messages on any developer kit, look up product information, or even sing a song. Over the coming months, this forum (soon with a utility similar to DEVCIM) will contain most of the development-related information you need for your developing projects.

Very shortly, you will see the removal of the NOVA, NOVB and NOVC NetWire sections. These placeholder names will be replaced by restructuring forum content and forum nomenclature. Look for changes in the OS sections as well.

Next month's issue of Bullets will include a complete layout of this new forum. Please feel free to start using the developer support section of this forum, GO NDEVSUP, immediately.

Happy_Programming!

Mad Poarch
Director
Developer Support/Service

ARTICLES:

Building a TLI Application with the NetWare Client SDK

This article provides an overview of Novell's TLI implementation, compares blocking mode with non-blocking mode, and describes the basic steps for building simple TLI applications with the SPX transport using the NetWare Client SDK. This discussion focuses primarily on TLI applications on the DOS and Microsoft Windows platforms, but also briefly discusses issues specific to OS/2.

The concepts in this article apply only to connection-mode TLI applications. Connection-mode implementations provide guaranteed delivery of messages and feedback on whether connections are solid and continually provide a path between multiple nodes. Connectionless implementations provide a basic method of sending or receiving messages, but do not guarantee delivery (on sends) and do not provide any feedback when destination nodes are not in receiving mode.

TLI applications written using the Client SDK can communicate not only with each other, but also with other NetWare Loadable Modules (NLMs) on the server.

Novell's TLI Implementation

TLI uses file handles that identify the communication paths or endpoints that the application opens. TLI could be described as a "state" machine; events occur based on the current state of individual file handles. The state of each file handle denotes what operations may be carried out. To understand TLI, you must understand the flow of events that are based on the state of file handles.

The NetWare Client Transport Protocol API for C and the NetWare Programmer's Guide for C provide additional information on TLI.

Blocking & Non-Blocking Modes

Novell's implementation of TLI allows you to select either blocking or non-blocking mode for each function. If you want to switch modes before a TLI function, call t_blocking() or t_nonblocking(). The ability to set the mode for each function can provide additional control depending on the particular operation. For example, as the sample Microsoft Windows TLI application discussed in this article shows, nearly all calls are carried out in non-blocking mode. The functions t_snddis() and t_rcvdis() are called in blocking mode to reduce the need for state checking. In the sample DOS TLI application presented in this article, the server application runs entirely in non-blocking mode (as specified by the O_NDELAY option in the t_open() function), while the client application runs wholly in blocking mode.

When you select blocking mode, functions run to their completion before relinquishing control back to your application. Although this approach works well in many programming situations, it provides little control over the endpoint when connections are terminated incorrectly or when communication with the other end of the connection is intermittent. For example, a blocking t_rcv() call will wait indefinitely for data to be received - as long as it thinks the other side is active. For obvious reasons, this scenario is inappropriate for multiple-connection applications. Non-blocking mode is used most frequently since most TLI servers are multiple-connection applications.

Sample DOS TLI Application

The Client Application

1. The function t_open()opens the endpoint in blocking mode for SPX. Whether you specify the "/dev/nspx" or the "nSPXII" transport, the SPX version will default to SPXII. Novell's TLI API libraries are designed for SPXII.
2. The t_bind() function binds the endpoint. Note: as an option, we have returned the endpoint information in the third parameter. This allows us to obtain the node address, including the socket number that is bound on the node. The bind operation is responsible for allocating the resources that are to be used for the specified handle.
3. The client application initializes the t_call structure, tcall. This structure in turn sets up the socket by setting the socket field, SPX address structure, spx_addr.ipxa_socket. (The server and client must synchronize on the same socket number.) The client then sets pointers to the appropriate address and option specifiers for the endpoint (the spx_addr and spx_options structures).
4. The client application calls t_connect() in blocking mode. Although an unsuccessful t_connect() will time-out in either blocking or non-blocking mode, you need to check the state for non-blocking mode to handle the time-out. Figure 1 contains code illustrating steps 1 - 4. FIGURE 1: Initializing and attempting to connect

   // initialize structures
   
   memset(&tcall, 0 , sizeof(tcall);
   memset(&spx_options, 0, sizeof(spx_options));
   memset(&spx_addr, 0, sizeof(spx_addr);
   
   if ((fd = t_open("/dev/nspx", O_RDWR,
                    (struct t_info *)0)) == -1) {
      t_error("\nopen of /dev/nspx failed");
      exit(2);
      }
   
   tbind.addr.len    = sizeof(spx_addr2);
   tbind.addr.maxlen = sizeof(spx_addr2);
   tbind.addr.buf    = (char *)&spx_addr2;
   
   if (t_bind(fd, (struct t_bind *)0,
              (struct t_bind *)&tbind) == -1) {
      t_error("\nbind failed");
      exit(2);
      }
   
   *(WORD *)&spx_addr.ipxa_socket[ 0 ] =  SPX_SOCKET;
   
   tcall.addr.buf                      = (char *)&spx_addr;
   tcall.addr.len                      = sizeof(spx_addr);
   tcall.addr.maxlen                   = sizeof(spx_addr);
   tcall.opt.buf                       = (char *)&spx_options;
   tcall.opt.len                       = sizeof(spx_options);
   tcall.opt.maxlen                    = sizeof(spx_options);
   if (t_connect(fd, &tcall, &tcall) == -1) {
      t_error("\nt_connect failed");
      if (t_errno == TLOOK && t_look(fd) == T_DISCONNECT)
          SPXDisconReason(fd);
      exit(2);
         }
      printf("\nt_connect successful, beginning send
   loop...\n");
   
   END of FIGURE 1
   

5. Once t_connect() is successful, the client application is ready to send and receive messages, and enters a send/receive loop. Since the client application is in blocking mode, every TLI function call must complete before control is returned to the application. Figure 2 shows the simple send/receive loop.

   FIGURE 2: Simple send/receive loop

   while (!kbhit()) {
       if (t_snd(fd, buf, strlen(buf)+1, 0) == -1) {
          t_error("\nt_snd failed");
          exit(2);
          }
       flags = 0;
       if (t_rcv(fd, buf2, sizeof(buf2), &flags) == -1) {
          t_error("\nt_rcv failed");
          if (t_errno == TLOOK && t_look(fd) == T_DISCONNECT)
             SPXDisconReason(fd);
          exit(2);
          }
   }
   
   END of FIGURE 2
   

6. After the send/receive loop has terminated, the client application disconnects and closes the connection. The function t_snddis() carries out the orderly disconnection from the server application and t_close() closes the endpoint.

The Server Application

The basic steps for building the server application are described below.

1. The server application calls the t_open() function to open the endpoint in non-blocking mode, specified by O_NDELAY. In this mode, you can check multiple file handles for events without waiting on any particular function to complete (Figure 3). However, once an event occurs, you must handle it as soon as possible.

   FIGURE 3: Non-blocking t_open call

   if ((fd = t_open("/dev/nspx", O_RDWR|O_NDELAY,(struct t_info
   *)0)) == -1) {
      t_error("\nopen of /dev/nspx failed");
      exit(1);
      }
   
   END of FIGURE 3
   

2. The server application uses one endpoint to listen for connection requests from the client side. When a request arrives, the server application opens a new file handle for each connection requested. The initialization steps are very similar to those for the client side (see "The Client Application," steps 1 - 3) but the server application also initializes the t_bind structure, tbind.

   This step is required in order to force the use of a particular socket with which the client application will try to connect. Figure 4 shows t_bind structure initialization. By default, if the tbind structure is not initialized, the client application will connect with a dynamic socket. The dynamic socket is automatically specified when the t_bind structure does not explicitly specify a socket number in the "spx_addr" field.

   FIGURE 4: t_bind structure initialization

   *(WORD *)&spx_addr.ipxa_socket[ 0 ] = SPX_SOCKET;
   tbind.addr.len                      = sizeof(spx_addr);
   tbind.addr.maxlen                   = sizeof(spx_addr);
   tbind.addr.buf                      = (char *) &spx_addr;
   tbind.qlen                          = 5; // outstanding
   events on endpoint
   if (t_bind(fd, &tbind, &tbind) == -1) {
      t_error("\nbind failed");
      exit(1);
      }
   
   END of FIGURE 4
   

3. Since the server application must deal with more than one file handle, it will need a basic control structure in which to store them. The array "nfd" is used to store file handles:

   int nfd[MAX_CLIENTS];

   Initially, the unused slots in the array are represented by the value -1 to allow you to recycle entries for new connections as sessions are terminated. When new connections are requested, the server application uses the first available slot for the new file handle.

4. The server application calls t_listen(), which allows it to accept connection requests from the client side. The t_listen() function uses the t_call structure, tcall, which is initialized just like it was for the client application (refer to Figure 1).
5. The server application continually checks the state of the opened endpoint for any events; it loops, testing the state of the original file handle, "fd," for events that need attention. For simplicity, the server application of the example DOS TLI application only checks the T_LISTEN state, and the default condition may end up doing nothing (continuing through the next iteration), depending on whether any sessions are currently active. (See Figure 6 below). Refer to the NetWare Client Transport API for C for more information on states.

   The next step is split into two sub-steps: Step 6A describes the acceptance of connection requests, and Step 6B describes the processing of existing sessions.

   1. New connections are accepted once a T_LISTEN state occurs on the original endpoint. Before accepting a new connection, the server application must obtain the first available slot in the "nfd" array that will store a new file handle. To obtain this slot, it calls getAvailablefh(), as shown in Figure 5 and Figure 6.

      FIGURE 5: Helper Functions

      void closeConnections()
      {
         t_close(fd);           // listening endpoint
         maxOpenedCount--;
         for (; maxOpenedCount > -1; maxOpenedCount--)
             t_close(nfd[maxOpenedCount]);
      }  // closeConnections
      
      //--------------------------------------------------------
      
      void disconnect( int fdIndex )
      {
         struct   t_discon discon;
         char   *msg;
         if (t_rcvdis(nfd[fdIndex], &discon) == -1) {
            t_error( "t_rcvdis failed" );
            closeConnections();
            exit( 2 );
            }
         switch( discon.reason) {
            case TLI_SPX_CONNECTION_FAILED:
                     msg = "Connection failed"; break;
            case TLI_SPX_CONNECTION_TERMINATED:
                     msg = "Connection terminated by client";  break;
            case TLI_SPX_MALFORMED_PACKET:
                     msg = "Internal SPX interface error -- malformed packet";
      break;
            default:
                     msg = "Unknown termination reason";
            } // switch
         t_unbind(nfd[fdIndex]);
         nfd[fdIndex] = -1;                     // mark as unused
         printf("\n\tDisconnected: %s\n", msg );
      } // Disconnect
      
      //--------------------------------------------------------
      
      int getAvailablefh()
      {
         int I, openfd;
         for (I = 0, openfd = -1; I < MAX_CLIENTS; I++) {
             if (nfd[I] == -1)
                return(I);
             } // for
         return(-1);
      } // getOpenSlot
      
      END of FIGURE 5
      

      FIGURE 6: Accepting a client connection request

      t_res = t_look(fd);
      switch (t_res) {
      case T_LISTEN:
         if ((openIndex = getAvailablefh()) < 0)  break;
         if ((nfd[openIndex] = t_open("/dev/nspx", O_RDWR|O_NDELAY,
                                          (struct t_info *)0)) == -1) {
            printf("\n\t[%d] - Client - t_open failed", openIndex);
            t_error("\n\tClient - t_open");
            closeConnections();
            exit(1);
            }
         if (t_bind(nfd[openIndex], (struct t_bind *)0,
             (struct t_bind *)0) == -1) {
            printf("\n\t[%d] - t_bind", openIndex);
            t_error("\n\tt_bind");
            closeConnections();
            exit(1);
            }
         listenResult = t_listen(fd, &tcall);
         if (t_accept(fd, nfd[openIndex], &tcall) == -1) {
            printf("\n\t[%d] - t_accept", openIndex);
            t_error("\n\tt_accept");
            closeConnections();
            exit(1);
            }
         acceptedCount++;
         printf("\n----- Total Accepted %d Connections\nAccepting 'index'
                [%d]-----", acceptedCount, openIndex);
         if (maxOpenedCount < MAX_CLIENTS - 1) maxOpenedCount++;
         newConnection = TRUE;
         defaultOn = FALSE;
      
      //--------------------------------------------------------
      // fall thru to "default" check on in coming data from
         any connection
      //--------------------------------------------------------
      
      default:
         :
      
      END of FIGURE 6
      

      After obtaining the first available slot, the server application opens a new endpoint using t_open() (in non-blocking mode), binds it to take care of the T_LISTEN state on the original file handle using t_listen(), and then finally accepts the connection with the t_accept() call. The original file handle and the new file handle are both parameters of this API, as shown in Figure 6.
   2. To process existing sessions, the server application checks each file handle for pending events as quickly as possible. When all events have been handled, the inner loop completes and the server application again checks for new connection requests before returning to this step again. The server application spends most of its time processing events, attempting to process them as quickly as possible.

      Although you could write a more efficient algorithm to handle this functionality, the process illustrated in Figure 7 presents the main issues. This test just echoes back the same message received.

      FIGURE 7: Client-Server Connection processing

         for (I = 0; I < maxOpenedCount; I++) {
            if (nfd[I] == -1) break;          // skip over unused slot
            t_res = t_look(nfd[I]);
            switch (t_res) {
               case T_DATA:
                  if ((len = t_rcv(nfd[I],  buf, sizeof(buf),&flags)) != -1) {
                     printf("\n[%d] Received: - '%s'",I,buf);
                     if (t_snd(nfd[I], buf, len, 0) == -1) {
                        printf("\n\t[%d]- t_snd", I);
                        t_error("\n\tt_snd");
                        closeConnections();
                        exit(1);
                        } // if
                     } // if
                  defaultOn = FALSE;
                  break;
      
               case T_DISCONNECT:
                  printf("\n[%d] Disconnection Requested...",I);
                  disconnect(I);         // cleanup local resources
                  defaultOn = FALSE;
                  break;
      
               default:
                  printf("\r[%d] state: %d", I, t_res);
                  break;
               } // switch
      
      END of FIGURE 7
      

6. The final step is closing the connections, including the original endpoint and all client connections. The T_DISCONNECT state (shown in Figure 7), handles the condition when a client session is terminated in an orderly fashion by the client side. In this case, the server application calls disconnect(), a local function (Figure 5), with the file handle at which the event occurred. To handle a T_DISCONNECT state, the server application must call t_rcvdis(), and then call t_unbind() and t_close() to close the file handle. Finally, the server application resets the "nfd" array to free the current slot for new connection requests.

To terminate the server application, the original endpoint must be shut down first by calling t_unbind(), t_close(), and then looping through each active connection and closing it. To keep the example application simple, the server application does not carry out a t_snddis() procedure; it simply closes the connections and exits, forcing any active connections to time-out on the client side. The time-out length depends on SPX parameters (primarily "SPX ABORT TIMEOUT") in the NET.CFG workstation configuration file, or the values in the SPX_OPT and SPXII_OPTIONS structures defined in TIIPXSPX.H. (Refer to the structures in this header file that name the specific fields that manage the time-outs values).

Example Microsoft Windows TLI Application

Three Microsoft Windows timers provide a means to implement non-blocking mode. These timers are used to delay for a very short interval; once they are triggered, the application sends an appropriate message that controls checking for a particular state on each file handle. The receive timer delays while checking the state on an active session. The connect timer delays while checking the state following a t_connect() attempt, waiting for a T_CONNECT state. Finally, the listen timer delays while checking the state following a t_listen(), waiting on a pending T_LISTEN state.

The original endpoint is initially opened in blocking mode. The Microsoft Windows TLI application calls t_blocking() after the t_bind() call returns successfully. Figure 8 contains a short code excerpt showing the timer and the condition that waits for a successful connection request.

FIGURE 8: Timers and connection request handling (Windows)

#define  CONNECT_TIMER_DELAY    1000
:
      case WAIT_FOR_CONNECT: /* wait for a connect - t_connect side */
         PrintString (hSendWnd,"--- Waiting for connection ---\r\n");
         t_res = t_connect(htli, (struct t_call FAR *)tconcall,
                           (struct t_call FAR *)NULL);
         if (t_res == -1 && t_errno != TNODATA) {
            PostMessage (parentWnd, TERMINATE, NULL, (DWORD)NULL);
            break;
            }
         connectTimer = SetTimer (hWnd, WAIT_T_CONNECT,
                                  CONNECT_TIMER_DELAY, NULL);
         if (!connectTimer) {
            PostMessage (parentWnd, TERMINATE, NULL, (DWORD)NULL);
            break;
            }
         t_tres = -99;
         /----------------------------------------------------/
         /------ falling through - loop until connected ------/
         /----------------------------------------------------/
      case WAIT_T_CONNECT:
         t_res = t_look(htli);
         switch (t_res) {
            case T_CONNECT:
               t_res = t_rcvconnect(htli, (struct t_bind FAR *)NULL);
               if (t_res == -1) {
                  break;
                  }
               // kill timer that was waiting to establish connection
               if (connectTimer) {
                  connectTimer = 0;
                  KillTimer(hWnd,WAIT_T_CONNECT);
                  }
               connected = 1;
               hclient = htli;     // client side only needs one handle
               nbytes = 1;      /* number of bytes to recieve or send */
               receiveTimer = SetTimer (hWnd, TLI_RECEIVE,
                                        RECEIVE_TIMER_DELAY, NULL);
               if ( !receiveTimer) {
                  PostMessage (parentWnd, TERMINATE, NULL, (DWORD)NULL);
                  }
               break;

           default:
               if (RETRY_MAX < retryCount++) {
                    // kill timer that was waiting on establishing
                    if (connectTimer) {
                       connectTimer = 0;
                       KillTimer(hWnd,WAIT_T_CONNECT);
                       }
                    PostMessage(hWnd, TERMINATE, NULL, (DWORD)NULL);
                    }
                 break;
            } /* switch */
         break;
:

END of FIGURE 8

FIGURE 9: Termination and closing handles

case TERMINATE:                // clean-up and exit application
    :
   if (terminated) {
      PostQuitMessage (0);
      break;
      }
   if (receiveTimer)  KillTimer (hWnd, TLI_RECEIVE);
   if (listenTimer)   KillTimer (hWnd, WAIT_T_LISTEN);
   if (connectTimer)  KillTimer (hWnd, WAIT_T_CONNECT);
   if (htli != -1) {
      // make it blocking - client side htli & hclient are same
      if (hclient != -1) {
         t_res = t_blocking(hclient);
         t_res = t_snddis(hclient, (struct t_call FAR *)NULL);
         t_res = t_nonblocking(hclient);
        :

END of FIGURE 9

OS/2 TLI Applications

#include <OS2.H>
#define NWOS2

Since configuration issues are an obstacle in OS/2, the NET.CFG file for Ethernet support requires that "Buffers" be set at a minimum of 1514 bytes, and the 802.3 frame type must be specified at the first frame type if more than one are used.

The TLI interface offers a method of accessing transport protocols. Although TLI client applications are currently limited to using IPX and SPX, TCP/IP support may be added in the future. TLI is easier to manage than the lower-level IPX/SPX protocols, and provides the added benefit of portability. Another benefit of using TLI is that it is consistent from platform to platform, and this consistency streamlines the development process.

The sample applications discussed in this article are available in their entirety on Novell's NDEVREL forum on CompuServe (Library 6, TLIAPPX.ZIP). For more information on the concepts discussed in this article, or to order the NetWare Client SDK, contact Novell at 1-800-NETWARE (1-800-638-9273) or 1-801-429-5588.

An Introduction to AIO

The AIO interface functions communicate with the AIO.NLM program which provides the services. AIO.NLM then works through a hardware driver written to AIO specifications. The driver communicates directly with the hardware.

This article provides an overview of basic AIO features and how to program for them. Structurally, this article parallels the example program, AIOSAM.NLM (see Figure 10 below), and can be used as extended documentation for it. AIOSAM.NLM demonstrates functions needed to acquire, configure, and communicate using an AIO port. AIOSAM.NLM can be downloaded in electronic format from NetWire (Library 7, AIOSAM.EXE). For more information on AIO, please refer to the AIO Services section of Optimizing NLM Performance or the NLM Library Reference Vol. 1 for additional details.

Serial Ports

Acquisition

Application can scan the pool of known ports using AIOGetFirstPortInfo() and AIOGetNextPortInfo(). These functions return basic information about a port, including availability, without acquiring it for use. They do not provide any information about the devices that are attached to the ports.

Capabilities

Configuration

Control

AIOSetExternalControl() provides direct control over the DTR and RTS lines. It can also generate a break signal and to alter the flow control settings.

Writing

AIOWriteData() may "succeed" but return a value of 0 (zero) bytes written if the buffer is full. The application program should note how many bytes are actually written and be prepared to resend any data that was not accepted into the output buffer.

Reading

Status

When communicating with an RS-232C device (such as a standard IBM-compatible serial port) it is often necessary to determine the status of non-data lines such as RI, DCD, DSR, and CTS. AIOGetPortStatus() returns that information through the extStatus bit mask. It also provides chgdExtStatus bit masks to indicate which status bits have changed.

Release

This article and the accompanying example program, AIOSAM.NLM are intended to demonstrate commonly used features of the AIO interface. If your application is modem control, you may be able to use parts of the example program with little or no modification.

FIGURE 10: AIOSAM.NLM example Asynchronous I/O (AIO) program

#include <stdio.h>
#include <stdlib.h>
#include <process.h>
#include <string.h>
#include <aio.h>

#define BUFFER_SIZE     128

int main(void)
{
   int                 rcode;
   int                 portHandle;
   LONG                count;
   WORD                state;
   char                buffer[BUFFER_SIZE];
   AIOPORTCAPABILITIES portCaps;

    /* Acquire available ports from COMx driver only */
   int       hardwareType  = AIO_COMX_TYPE;
   int       boardNumber   = AIO_BOARD_NUMBER_WILDCARD;
   int       portNumber    = AIO_PORT_NUMBER_WILDCARD;

   if ((rcode = AIOAcquirePort( &hardwareType,
      &boardNumber, &portNumber, &portHandle)) !=
      AIO_SUCCESS)
   {
      printf("AIOAcquirePort failed, rcode=%d.\n", rcode );
      exit(1);
   }

   printf("Acquired port for driver %d, board %d,
         port %d.\n", hardwareType, boardNumber,
         portNumber );

   /*  Get the high-level capabilities of the acquired
       port, not driver caps  */
   if ((rcode = AIOGetPortCapability(portHandle,
      &portCaps, NULL)) != AIO_SUCCESS)
   {
      printf("AIOGetPortCapability failed,
            rcode=%d.\n", rcode );
      exit(1);
   }

   /*  Verify that structures are current or newer  */
   if (portCaps.returnLength < sizeof(portCaps))
   {
      printf("Obsolete structures in use!\n");
      exit(1);
   }

   /*  Verify that the port can handle 2400 baud  */
   if ((portCaps.minBitRate > AIO_BAUD_2400)  ||
      (portCaps.maxBitRate < AIO_BAUD_2400))
   {
      printf("Port cannot be configured for 2400bps
            rate requirement.\n");
      exit(1);
   }

   /*  Configure the port for use  */
   if ((rcode = AIOConfigurePort(portHandle,
      AIO_BAUD_2400, AIO_DATA_BITS_8,
      AIO_STOP_BITS_1, AIO_PARITY_NONE,
      AIO_SOFTWARE_FLOW_CONTROL_ON)) != AIO_SUCCESS)
   {
      printf("AIOConfigurePort failed, rcode=%d.\n", rcode );
      exit(1);
   }

   /*  Set DTR and RTS on  */
   if ((rcode = AIOSetExternalControl(portHandle,
      AIO_EXTERNAL_CONTROL,
      AIO_EXTCTRL_DTR | AIO_EXTCTRL_RTS)) !=
      AIO_SUCCESS)
   {
      printf("AIOSetExternalControl failed,
            rcode=%d.\n", rcode );
      exit(1);
   }

   /*  Send an AT attention string to the modem  */
   strcpy(buffer, "AT\r");
   if ((rcode = AIOWriteData(portHandle, buffer,
      strlen(buffer), &count)) != AIO_SUCCESS)
   {
      printf("AIOWriteData failed, rcode=%d.\n", rcode );
      exit(1);
   }

   if (count < strlen(buffer))
      printf("AIOWriteData: incomplete write, only %d
            bytes written.\n", count );

   /*  Poll until at least 3 characters to be read  */
   do
   {
      if ((rcode = AIOReadStatus(portHandle, &count,
         &state)) != AIO_SUCCESS)
       {
         printf("AIOReadStatus failed, rcode=%d.\n", rcode );
         exit(1);
       }
     ThreadSwitch();
   } while (count < 3);

   /*  Read the input buffer  */
   if ((rcode = AIOReadData(portHandle, buffer,
      BUFFER_SIZE, &count)) != AIO_SUCCESS)
   {
      printf("AIOReadData failed, rcode=%d.\n", rcode );
      exit(1);
   }

   /*  Verify attention string echoed back by modem  */
   if (strncmp(buffer, "AT\r", 3) != 0)
      {
      printf("Modem did not echo, saw \"%c%c%c\".\n",
            buffer[0], buffer[1], buffer[2] );
      }
   else
      printf("Modem echo confirmed.\n");

   /*  Release the port  */
   if ((rcode = AIOReleasePort(portHandle)) !=
      AIO_SUCCESS)
   {
      printf("AIOReleasePort failed, rcode=%d.\n", rcode );
      exit(1);
   }

   return 0;
}

END of FIGURE 10

DEVELOPER NEWS:

The AppWare Foundation: In Depth

The AppWare Foundation is composed of programming libraries and a cross-platform API for accessing operating system, user interface, and connectivity services with traditional 3GL programming tools. The AppWare Foundation is divided into different service groups that share many characteristics with traditional libraries, but there are important differences.

Similar to a library, these service groups are a collection of utility routines that are reusable within and among applications. Services encapsulate their routines with associated data elements, and some services rely on and inherit capabilities from other components. These services are implemented as modules using C and as classes using C++.

The AppWare Foundation collects the various types of services and designates them as three separate series:

• The Foundation Series
• The User Interface Series
• The Connectivity Series

FIGURE 11: AppWare Foundation Series

     FOUNDATION          CONNECTIVITY        USER INTERFACE
SERIES:             SERIES:             SERIES:

Character           Action              Application
Data                Clipboard           Box
Error               Link                Button
File                Pipe                Dialog
Font                Task                Display
Graphics                                Edit Text
Instance                                Help
Key                                     Item
Memory                                  List
Message                                 Menu
Module                                  Slider
Pointer                                 Standard
Preferences                                  Table
Print                                   Void
Resources                               Windows
System

END of FIGURE 11

• Multiple lines of text
• Scrollable viewing
• Clipboard cut, copy, and paste
• Single font in a view
• Maximum 32,767 characters
• Left, center, and right justification

The Foundation Series

FIGURE 12: Foundation Series Components

Character -    (Chararacter handling) Allows developer to deal with internationalization issues
relating to character encoding and types.

Data -    (Data conversion & storage) Provides functionality similar to atoi, itoa, sprintf & sccanf.
Also supports buffers, lists, and trees.

Error -   (Error handling) Handles errors such as device failures, media failures, and media
overflows. Callbacks used for error control.

File -    (File I/O & system management) Supports file I/O, file/directory path manipulation,
directory traversal, copying files & aliases.

Font -    (Font control) Allows platform-independent font selection & sharing operations. Can query
AppWare Foundation for font info.

Graphics -     (Graphics package) Provides a wealth of capacities incl. lines, polygons,
rectangles, text, patterns, icons, bitmaps, palettes, etc.

Instance -     (Autonomous instance management) Provides shared functionality for all AppWare
Found. instances, incl. User Interface Series instcs.

Key -     (Keyboard status & management) Provides a universal keycode interface allowing
programmers to code for various keyboards.

Memory -  (Memory management) Provides routines for allocating, locking, unlocking,
resizing, and deallocating memory from the heap.

Message - (Message passing system) Used for communication with AppWare Foundation
instances. Implemented on top of native messaging system.

Module -  (Module management) Provides routines for creating shared libraries. Supports
static, dynamic & runtime linking; & multitasking.

Pointer - (Pointer/cursor manipulation) Allows you to get and set the pointer/cursor position,
as well as constrain the cursor position.

Preferences    (User preference management) Provides the ability to access & modify preference
settings in application-specific files.

Print -   (Printing support) Provides functions to open and close print devices, setup page & print
options, & control documents & pagination.

Resources -    (Resource management) Enables loading of user-defined resources and standard
system resources.

System -  (Operating system attributes) Allows querying of platform-specific attributes,
including number of screens, and workstation info.

END of FIGURE 12

For file management, the Foundation Series provides standard I/O functions, file and directory management, resource management facilities, and a way to deal with user preferences in a platform-independent manner.

To support the developer with flow of control issues, the AppWare Foundation Series provides an error handling facility and incorporates its own polymorphic message-passing system. The AppWare Foundation message system is implemented as a hand-crafted layer on top of the native message system. This design allows the developer to gain access to the native message system, if necessary.

The Font Component Family provides support for font selection and management that is platform-independent. To support application internationalization, the Character Component provides support for processing character data or text, independently of language and character encoding (Unicode, WorldScript, ASCII, DBCS, DOS-OEM). The Foundation Series families also support device management, including support for printers, keyboard control, system control, and graphics output to non-screen devices.

The User Interface Series

• Users base their impressions of an application upon the UI, with respect to how the application looks and how easy it is to use.
• The UI typically consumes a large percentage of the engineering resources required for application development.

FIGURE 13: User Interface Series Components

Application    (Application instance support) Manages global interface facilities, including
system pallets, system notification & appl. menus.

Box -     (Box instance support) Supports an interface instance with a border, which is used as a
container for buttons and other objects.

Button -  (Button instance support) Supports single-, double-, and tri-state selection (button)
mechanisms.

Dialog -  (Dialog control) Provides functions, messages and data structures used to create a
variety of dialogs.

Display - (Display instance support) Supports an interface used to display static information
to the user.

Edit Text -    (Edit Text instance support) Supports an interface object used as an input device
for entering and editing text.

Help -    (Help instance support) Provides centralized and automated help processing for both
continuous & immediate help.

Item -    (Interface data management) Provides facilities for manipulating many data types in
AppWare Foundation instances.

List -    (List instance support) Supports an interface instance used for both data display and as a
single-dimension selection device.

Menu -    (Menu instance support) Supports menu bars pop-up menus, cascade menus, option
menus, and button menus.

Slider -  (Slider instance support) Supports scroll bars as well as input devices for selecting
a value within a fixed, programmer-defined range.

Standard -     (Standardized interface dialog support) Supplies several dialogs for selecting files,
fonts, colors, printers, etc.

Table -   (Table instance support) Provides an inter- face for displaying, selecting and
editing data from a two-dimensional grid.

Void -    (Void instance support) Provides an interface instance, whose behavior can be defined by
the developer.

Window -  (Window instance support) Provides support for modal, modeless, and floating
windows.

END of FIGURE 13

• For Microsoft Windows - supports Microsoft Windows GUI standards
• For Macintosh - supports Apple Macintosh GUI standards
• For UNIX - supports Motif GUI standards
• OS/2 - support for OS/2 GUI standard is pending

• For situations in which only simple dialogs are required, the Dialog Component provides a set of functions, messages, and data structures that support a variety of dialogs. The Dialog Component supports the design and development of most of the modal dialogs found in applications. A special function is provided to easily display message boxes (also called "alerts").
• For more complex interfaces, built-in controls that can be nested are available. These controls include windows, voids, and boxes (which usually contain buttons, boxes, edit text areas, display areas, lists, sliders, tables, etc.). A large variety of menu types are also available. To provide even more flexibility, a sophisticated GUI data management facility allows the developer to associate any combination of text and graphics inside the controls.

Connectivity Series

FIGURE 14: Connectivity Series Components

Action -  (Event management) Provides access to high-level application messages about
events.

Clipboard -    (Data transfer) Allows transfer of data within and between applications in support
of the "cut-copy-paste" model.

Link -    (Object linking) Provides support for object linking and embedding using the OLE 2.0
standards.

Pipe -    (Pipe and socket management) Supports creation, querying, and closing of pipes for
streamed communication between tasks.

Task -    (Task manipulation) Supports launching, executing, and enumerating tasks in a multitasking
environment.

END of FIGURE 14

Named pipes can be used in a client-server environment. In this situation, a server will create a named pipe as a published service; clients can then access the pipe by name. With the Pipe Network Extension, named pipes can be accessed by remote clients. The Connectivity Series also provides a portable mode to define objects so that scripting languages can be used to drive your application.

AppWare Foundation Availability

To request white papers on AppWare, call 1-800-554-4446 or 1-512-345-1145.

The AppWare Foundation: International Support

• Superset classification of locale identifiers--script, language, region, version
• Transparent compatibility with all mainstream character encodings
• Support for character-by-character processing (no performance penalties)
• Encoding sensitive newline handling, including support for Unicode line and paragraph separators
• Language-sensitive collation, comparison, and case transformations
• Locale-sensitive formatting and scanning of numbers, dates, times, currency
• Extended character type (ctype) information, including Unicode types
• Transparent keyboard input handling for multibyte characters
• Association between fonts and scripts
• Full locale information: script and language attributes, number, date/time, and currency formats
• Enumeration of installed locales and selection of default locale
• Design that allows for future multi-language support

Character-Encoding Support

• Unicode - standard Unicode double-byte encoding (Windows NT)
• WorldScript - WorldScript I (single-byte) and WorldScript II (multibyte) encodings (Macintosh)
• Standard ASCII single-byte encoding (UNIX)
• DBCS - Double Byte Character Set multi-byte encoding (Windows)
• DOS-OEM (Microsoft Windows, OS/2, and DOS)

Special Features Support Unicode

• Compile-time switches allow optimizing for Unicode and transparent use of wide (two-byte) characters and strings
• Transparent use of PARAGRAPH SEPARATOR and LINE SEPARATOR characters
• Extended character type information, including non-spacing and directional types
• Non-spacing mark handling for partitioning and truncating text
• Mapping to composite or precomposed character forms
• Mapping of compatibility zone characters to their canonical form
• For platforms supporting Unicode, conversion between Unicode and other native encodings

Character Encoding Without Performance Penalties

In addition, the AppWare Foundation itself can be configured to support only single-byte or Unicode encodings, if desirable. This provides improved performance for applications that will not be used in a multibyte environment.

Depending on whether an application is being compiled for Unicode or not, the basic AppWare Foundation character data types are redefined to be either one or two bytes in size, and strings are defined similarly. This allows character data to be treated independently of size, and allows some simple tasks, such as string termination, to be performed without the use of special macros. The detailed rules for ensuring that processing of character data is performed independently of character encoding are described in the AppWare Foundation technical documentation.

Locale Definition

For systems that support multiple installed locales, access to the list of locales and selection of a default locale is provided via the Character Software Component Multilocale Extension. True multilingual support (concurrent use of multiple locales for different languages) is not currently available, pending the availability of related OS features. However in preparation for multilingual support, all AppWare Foundation functions and macros that perform text processing accept locale indentifiers as parameters.

OEM Codepage & Microsoft Windows

Applications developed with the AppWare Foundation may choose to disallow selection of OEM fonts using the Font Software component family. Other applications may allow selection of both ANSI and OEM fonts, in which case the script identifier associated with a font can be used to distinguish between them. A similar situation occurs in the use of the Symbol fonts on all platforms, and is treated in the same manner.

Since the DOS file system uses the OEM character set for all file and path names, file and path names used in a Microsoft Windows application must be representable in the OEM character set. This is easily accomplished using the AppWare Foundation since on the Microsoft Windows platform all Foundation routines that interact with the file system translate to and from OEM when necessary.

Data entry of files names limited to the OEM character set is supported via the Edit Text and List software component families. Utilities are also provided for validating arbitrary text to be used as file or path names. To support data exchange with native DOS applications, utilities are provided for explicitly translating between OEM and non-OEM text.

Multiple Script Systems & Macintosh

Currently, no standard mechanism or data structure exists for storing the association between text and language (or script). Although it is possible to embed the language or script information in the text itself, no standard way of doing this exists and this technique is generally discouraged. The recommended approach is to store the language or script identifier separately from the text itself, along with other "fancy text" information such as font and color.

Novell Announces GNU Tools

The GNU development tools are a set of freely redistributable tools and utilities that are widely used and supported by almost all major UNIX environments. The development tools consist of a C compiler called gcc, a C++ compiler called g++, an assembler called Gas, and a debugger called gdb. Other utilities support the development environment including binary utilities, and editor, document formatting tools, a documentation browser, and a patch installer.

With GNU tools for NetWare, developers can use UnixWare to build single-source NLMs that can be deployed on all server platforms, supported by PIN (Processor Independent NetWare). Network applications and services such as messaging, database, telephony or imaging will be delivered on Intel- and RISC-based NetWare platforms including Digital's Alpha AXP, Hewlett Packard's PA-RISC and Sun Microsystem's SPARC. Digital Equipment, Hewlett Packard, and Sun Microsystems, all of whom have announced versions of NetWare for their RISC platforms, are working with Cygnus and Novell to enhance the GNU tools for their platforms as well.

The GNU tools will be included in the AppWare developer offerings including the NLM SDK. The product will be offered through Cygnus Support and will be available Q1 '94. Pricing of support and SDKs will be announced when the product is available.

Get Involved in the Compass Program

The Compass program provides a channel through which application developers, including Independent Software Vendors (ISVs), consultants, and in-house application developers, can work directly with Novell to:

• Communicate their needs to the Novell Engineering and Product Marketing
• Provide feedback on Novell APIs and future development product directions.

Novell offers the Compass program to members of Novell's Developer Programs members and the UnixWare Developer Program. The Compass program includes the Novell Advisory Council and Special Interest Groups (SIGs).

The Novell Advisory Council

Special Interest Groups (SIGs)

• Phase 1: Technology Preview - during the development of a new technology, Novell will hold a Technology Preview to consult with developers on the proposed product direction and whether it will meet developers' needs.
• Phase 2: Specification Review - after a product specification has been prepared for the new technology, a Specification Review will be held to gather feedback on proposed APIs and to determine if these APIs will meet developers' needs.
• Phase 3: SIG Workshop - after the new technology has been released as a development product to developers, a SIG Workshop will be held to discuss development issues to the new technology and development concerns.

Developers may join existing SIGs or propose new ones. Each SIG will have one representative on the Novell Advisory Council to ensure that the needs of all developers are represented in the overall Novell application framework architecture. In addition to exchanging information by e-mail and phone, SIGs will meet two to four times each year.

For more details about the Compass program, please call 1-800-NETWARE (1-800-638-9273) or 1-801-429-5588 in the U.S and Canada. In all other locations, call your local Novell sales office and ask for the information on the Novell Professional Developers' Program.

You can also fax inquiries to 1-512-794-1773 or send an e-mail message to one of the following addresses:

• MHS library @ Novell
• CompuServe:>MHS:library@Novell

See the Calendar of Upcoming Events below for SIGs on Security, Document Management, and Telephony to be held in the coming months.

NetWare Application Notes Back Issues

TECHNICAL INSIGHTS:

Using Directory Handles (NetWare Client SDK v1.0d)

To illustrate, the drive handle returned from NWParseNetWarePath() corresponds to a mapped drive and should not be used directly. Instead, allocate a drive handle using NWAllocTemporaryDirectoryHandle() or NWAllocPermanentDirectoryHandle(); the drive handle returned by these functions can be used for any purpose by your application.

APIs that scan or gather information on directory or file entries cannot use the directory handle from NWParseNetWarePath() directly. APIs like NWScanFileInformation2() and NWScanDirEntryInfo() require that the directory handles to be set to the parent directories that contain the item to scan. The item itself is the file or directory entry supplied to the API via the "searchPattern"/pathname parameter.

For example:

  VOL1:\DIR1\DIR2\ENTRY

• Directory handle is set to VOL1:\DIR1\DIR2.
• ENTRY can be a directory or a file.

Btrieve v5.x Status 109 (Transaction Too Complex) (NetWare Btrieve (NLM) v5.15)

The latest set of patches for NetWare Btrieve (NLM) v5.15 introduces a new status code, status 109 (Transaction Too Complex) added by patch #95. This status code was created to compensate for applications inserting large numbers of records into their files while inside an explicit Begin Transaction loop and receiving status 18s.

The status 18 is returned because NetWare Btrieve uses a two-byte or 16-bit counter for pages in the preimage file. This counter has now been changed to allow a preimage file of 64 MB to be created before the new error 109 is returned. When the error occurs, the application may either end or abort the transaction without file corruption. Operations on other Btrieve files (not the file whose preimage file has exceeded 64 MB) can still be performed successfully.

New Btrieve Status 130 (Ran Out Of System Locks) (NetWare Btrieve (NLM) v6.x)

With any version of Btrieve before v6.10b, the abend may occur when NetWare Btrieve runs out of system locks and either the system is under heavy use, or a certain combination of start-up parameters are used. The September patch release will ensure that NetWare Btrieve monitors its supply of system locks and returns a status 130 to applications trying to perform operations requiring system locks if none are available.

NetWare Btrieve uses system locks to lock pages in v6.x files that are changed during Insert, Update and Delete operations. These locks are held for the duration of the operation or until the transaction, if any, ends or aborts.

The number of system locks Btrieve can use depends on two of its start-up parameters: LocksPerClient ("Number of Locks" in BSETUP, "l" on the BTRIEVE.NLM command line) and MaxClients (not directly set by BSETUP, "s" on the BTRIEVE.NLM command line -not the BSPXCOM.NLM command line). The maximum number of system locks Btrieve can allocate is:

#systemLocks = 65,536 - ( l * s ).

1. A very large transaction (e.g., thousands of records inserted),
2. Many users performing large transactions concurrently.

If you are in a transaction and receive a status 130, you should end or abort the transaction. You could then retry the operation; other users may have exhausted NetWare Btrieve's system locks and may have ended or aborted their transactions.

WLINK Error 2067 (Network C for NLMs v2.0(e))

Unresolved External Error with Microsoft C (NetWare Client SDK v1.0d)

This situation occurs because the import library, NWCALLS.LIB, was created with Borland utilities. In most cases, import libraries created with the Borland IMPLIB.EXE utility are compatible with Microsoft, but NWCALLS.LIB is not. To resolve this situation, either create a new import library with Microsoft's IMPLIB.EXE utility or specify each function in the IMPORTS section of the application.

NetWare Btrieve v5.x Step Operations (NetWare Btrieve (NLM) v5.x)

This situation only occurs if Btrieve 6.x or 5.x engines are used with files in 5.x format; it does not occur with NetWare Btrieve v6.x files.

Converting the NetWare Btrieve files from v5.x to v6.x format will resolve the situation. If, however, you wish to leave the files in NetWare Btrieve v5.x format, there are three possible workarounds:

• Alter your program to devote at least one byte (beyond the fourth byte) in the record to hold a non-zero value.
• Create the Btrieve file using the compression option.
• Create the Btrieve file using the variable-length record option.

Status 330 on a WHERE Clause (NetWare SQL v3.x)

SELECT * FROM <table> WHERE <logical type> = 'T'

This status code is not the result of a problem in NetWare SQL v3.0. Although NetWare SQL v2.11 allows the above statement, it should not.

Drive Number Count & NetWare Client SDK (NetWare Client SDK v1.0d)

OS/2 Requester v2.01 Traps NWCALLS.DLL (NetWare OS/2 SDK v2.01)

While there is no solution at this time, this situation will be resolved in the next patch for the OS/2 requester.

Status 4 Occurs with Different Alternate Collating Sequences (NetWare Btrieve (NLM) v5.x)

When using different ACSs for separate files, make sure that the names for each ACS are different.

NWATTRIBUTES Not Pre-Defined (NetWare Client SDK v1.00)

In place of NWATTRIBUTES, define a variable "attributes" of type DWORD.

LogLogicalRecord() & Exclusive Mode (NLM SDK for NetWare 4.0 v1.0)

This situation has been reported to Novell Engineering. For now, use semaphores instead of the logical records.

Status 36 on Begin Transaction (NetWare Btrieve (NLM) v6.10)

In addition, if the workstation is configured for local and requester access, a Begin Transaction operation will also fail with a status 36 if the client (local) copy of Btrieve is not configured for transactions as well. This is true even if no local data file has been or will be accessed.

To prevent the status 36 from being returned on a workstation configured for both client and requester access, also configure the local engine for transactions. To accomplish this in the DOS environment, load BTRIEVE.EXE with /t:<file>.In the Microsoft Windows environment, specify options= /t:<file> in the WIN.INI file's [btrieve] paragraph.

If no local data files will be accessed, you can also resolve the situation in the DOS environment by not loading BTRIEVE.EXE or in the Microsoft Windows environment specifying local=no in the [brequestDPMI] paragraph of NOVDB.INI.

NET.CFG For TLI Under OS/2 (NetWare Client SDK v1.0d)

To prevent t_connect() from failing, set the following in the Link Support section of the NET.CFG:

Link Support
  Buffers x 1514

Using BASIC FIELD statements with Btrieve for Windows (Btrieve for Windows v5.10)

Do not use LET or INPUT statements to assign values to FIELD variables. Instead, use the LSET or RSET operator. Once a variable name is fielded, it points to the correct place in the random file buffer. If a subsequent INPUT or LET statement with that variable name is executed, the variable's pointer is moved to string space, therefore no longer pointing to the random file buffer.

LSET left justifies the string and pads with blanks to the indicated FIELD length. RSET right justifies the string and pads with blanks to the indicated FIELD length. FIELD statements work only with string variables.

Changing Btrieve 5.10a Interrupt (Btrieve for DOS v5.10a)

Under Btrieve for DOS v5.10x, change the code as shown in Figure 15.

FIGURE 15: Changing Btrieve v5.10a interrupt

ren btrieve.exe btrieve <cr>
debug btrieve <cr>
-r <cr>                 ;get the value of the cx register.
-s 0L[cx] 7b 25 <cr>    ;search for "set interrupt" where [cx] is value
                        ;of cx register obtained above.
                        ;
                        ;the search returns THREE addresses
  ssss:zzzz             ;DO NOT EDIT THE FIRST ADDRESS !!!
  ssss:xxxx             ;
  ssss:yyyy             ;
                        ;
-e ssss:xxxx            ;edit first address to change interrupt
   ssss:xxxx 7b.        ;address one is returned showing value of 7b.
                        ;Prompt is waiting for the new interrupt value.
               __ <cr>  ;Enter the value of the new interrupt.
-e ssss:yyyy            ;edit second address to change interrupt
   ssss:yyyy 7b.        ;address two is returned showing value of 7b.
                        ;Prompt is waiting for the new interrupt value.
               __ <cr>  ;Enter the value of the new interrupt.
-s 0L[cx] 7b 35 <cr>    ;search for "check interrupt" where [cx] is value
                        ;of cx register obtained above.
   ssss:xxxx            ;the search returns ONE address
-e ssss:xxxx            ;edit that address to change interrupt
   ssss:xxxx 7b.        ;that address is returned showing value of 7b.
                        ;Prompt is waiting for the new interrupt value.
               __ <cr>  ;Enter the value of the new interrupt.
-w <cr>                 ;write changes to disk
-q <cr>                 ;quit debug
ren btrieve btrieve.exe

END of FIGURE 15

NIBBLES AND BITS

Fast Answers to Common Questions

NetWire

• General
• Btrieve
• NetWare SQL
• Client SDK
• NLM SDK
• Mac Products
• Communication Products
• Imagery
• DPMS

Tip When you try to unzip a self-extractable patch/NLM file you have downloaded from NetWire, always use the "-d" option to rebuild the original directory structure.

NetWare System Calls for DOS

• Add Trustees
• Get Connection's Open Files
• Get Connections Using File
• Get File Server Info
• Get Object Disk Restrictions
• Obtain File or Subdirectory Information
• Scan Bindery Object Trustee Paths
• Scan Entry for Trustees
• Get Semaphore Information.

• Clear Connection Number
• Get Connection Information
• Get Physical Record Locks By File
• Get Network Serial Number
• Set Directory Disk Space Restriction
• Add User Disk Space Restriction

Network C for NLMs

A - Error 5 is an NCP error code indicating a broadcast error. The most likely reason for LoginToFileServer to return this code is if the "Reply To Get Nearest Server" parameter is set to "OFF" for the server. It will take the server longer to locate other servers on the network with this parameter set to OFF, and if an attempt is made to log in to a remote server that is not known the login may time out before the remote server's destination has been found.

This error is generally returned only when the server has just been started or when RESET ROUTER has just been run on the console. It does not seem to occur if "Reply to Get Nearest Server" is set to "ON."

NetWare Btrieve (NLM) v6.10

A - This message results from improper installation of the Btrieve NLM. To install the NLM properly, obtain BTR61.EXE and perform the following ten steps:

1. Create a temporary sub-directory (for example, \TEMPDIR).
2. Copy BTR61.EXE to \TEMPDIR and type BTR61.EXE -d. (This step creates two subdirectories, \SYSTEM and \PUBLIC and copies appropriate files into each.)
3. Back up all files on the server where Btrieve will be installed.
4. Copy the files from \TEMPDIR\SYSTEM into \SYSTEM on the server.
5. Copy all the files from \TEMPDIR \PUBLIC to \PUBLIC on the server.
6. At the server console prompt, type "BSTOP" to unload the existing versions of BTRIEVE.NLM and BSPXCOM.NLM.
7. At the server console prompt, type "UNLOAD CLIB".
8. At the server console prompt, type "LOAD CLIB" to load the latest version of CLIB.
9. At the server console prompt, type "AFTER311".
10. At the server console prompt, type "BSTART" to load BTRIEVE and BSPXCOM with default values.

• BC7XBTRV.ASM
• BC7RBTRV.OBJ
• BC7PBTRV.OBJ
• COBPBTRV.OBJ
• MFXBTRV.OBJ
• COBRBTRV.OBJ
• REALBTRV.OBJ
• MFXBTRV.BIN
• MF2BTRV.BIN

NetWare for SAA Tools SDK

A - The NetWare for SAA Tools SDK is now bundled with NetWare LU6.2 Tools v1.4, NetWare 3270 Tools v2.0 and the Netware Open NetView SDK v1.0. The NetWare 3270 LAN Workstation software for DOS and Microsoft Windows are now being sold and supported by AttachMate. To contact AttachMate, call 1-800-426-6283. NetWare LU6.2 and NetWare 3270 Tools are now supported on CompuServe in Novell's NDEVSUP forum (Library 7).

DEVELOPER EDUCATION:

Available Novell Developer Education Courses

904 - Btrieve: An Overview
905 - Programming with Btrieve
907 - Xtrieve PLUS
911 - NetWare Database Administrator
912 - Programming with NetWare SQL
930 - Developing NetWare Loadable Modules (NLMs)
940 - NetWare Programming: Basic Services
945 - NetWare Programming: Protocol Support

CURRENT PATCHES FOR NOVELL DEVELOPMENT TOOLS

When calling, be ready to provide a shipping address, disk preference (5.25", 3.5", HD, or DD) and, if you prefer overnight delivery, your company's Federal Express account number. If you do not provide a Fed Ex account number, the patch disk will be sent to you via regular mail.

Updated NetWare API SDK components can be obtained from Novell's NDEVREL forum on CompuServe. For more information on Novell developer programs contact Novell at 1-800-NETWARE (1-800-638-9273) or 1-801-429-5588.

Novell's Developer Relations Automated Fax System

CONTACTING NOVELL

Developer Support

Voice

Fax

Developer BBS

E-mail: CompuServe

E-mail: MHS

E-mail: Internet (SMTP)

NetWire on CompuServe

Novell Products and SDKs

DeveloperNet Labs

Novell Developer Relations

Voice

Fax

NetWire on CompuServe

E-mail: MHS or Internet (SMTP)

ERRATA

The dates should have read, "Sept. 12, 1992," and "9/12/92." We apologize for any confusion caused by this error.

ACKNOWLEDGMENTS

Special thanks to the Developer Support, Development, Developer Relations, Product Marketing, and Marketing Communications staff who contributed time and valuable input.

(c) 1993 Novell, Inc. All rights reserved.

Novell, the N design, NetWare, Btrieve, XQL, LAN WorkPlace, NetWare Name Services and LANalyzer are registered trademarks; NetWare Loadable Module, NLM, Global MHS, NetWare MHS, NetWare System Calls for DOS, NetWare Runtime, NetWare SQL, NetWare Btrieve, NetWare C Interface for DOS, NetWare RPC, NetWare RPC 386, NetWare LU6.2, Report Executive, NetWare Asynchronous Communication Services (NACS), NetWare Asynchronous Services Interface (NASI), NetWare Management System, NetWare 3270 LAN Workstation, Xtrieve PLUS, DeveloperNet Labs, IPX, and MacIPX are trademarks; and NetWire and Professional Developers' Program are service marks of Novell, Inc. IBM and OS/2 are registered trademarks, and NetBIOS and SAA are trademarks of International Business Machines Corporation. Microsoft is a registered trademark, and Windows, Windows NT and Microsoft QuickBasic are trademarks of Microsoft Corporation. Apple and Macintosh are registered trademarks of Apple Computer, Inc. CompuServe is a registered trademark of CompuServe Corporation. Sun Microsystems and NFS are registered trademarks; and TI-RPC is a trademark of Sun Microsystems, Inc. UNIX is a trademark of UNIX Systems Laboratories, Inc. in the USA and other countries. UNIX Systems Laboratories is a wholly-owned subsidiary of Novell, Inc. Univel and UnixWare are trademarks of Univel, Inc. WATCOM and WATCOM C are registered trademarks of WATCOM Systems, Inc.