Developer Pointers
Articles and Tips: article
01 May 1997
Novell Technical Information Documents
All of the Technical Information Documents (TIDs) discussed below are available at the following locations:
The Novell Technical Solutions Database on CompuServe (GO NTID)
The DeveloperNet Support World Wide Web site (http://devsup.novell.com)
The DeveloperNet Support Bulletin Board (801-861-5836)
Visual Basic 3.0 Sample Code
Author: |
CW |
Document ID: |
TID101176 |
Date: |
3/21/97 4:40 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
VBPASWRD.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
This sample code in Visual Basic 3.0 demonstrates how to change the users password.
API calls include the following:
NWDSCreateContext() |
|
NWDSChangeObjectPassword () |
|
NWDSFreeContext() |
File Information
Self-Extracting File Name: VBPASWRD.EXE
Files Included: |
Size |
Date |
Time |
VBPASWRD.TXT |
(this file) |
||
NWDSPASS.MAK |
89 |
3-21-97 |
4:39 PM |
NWDSPASS.BAS |
356 |
3-21-97 |
4:39 PM |
NWDSPASS.EXE |
7244 |
3-21-97 |
4:39 PM |
NWDSPASS.FRM |
1891 |
3-21-97 |
4:39 PM |
VBPASWRD.TXT |
2087 |
3-21-97 |
4:39 PM |
VBPASWRD.MSG |
221 |
3-21-97 |
4:39 PM |
NetBasic Web Demo - File System Access
Author: |
BA |
Document ID: |
TID101155 |
Date: |
3/14/97 5:28 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XNTBFS1.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
This NetBasic Web demo shows how to access the NetWare file system to build dynamic Web pages. This demo, called Thumb, builds a Web page of thumbnail graphic images and links them to the real graphic image.
To demonstrate how to call THUMB.BAS, another script called RUNTHUMB.BAS is also provided.
THUMB.EXE contains the entire package of scripts and some sample graphic images for demonstration purposes.
File Information
Self-Extracting File Name: XNTBFS1.EXE
Files Included: |
Size |
Date |
Time |
|
XNTBFS1.TXT |
(this file) |
|||
RUNTHUMB.BAS |
9262 |
3-14-97 |
5:27 PM |
|
RUNTHUMB.TXT |
1235 |
3-14-97 |
5:27 PM |
|
THUMB.BAS |
11038 |
3-14-97 |
5:27 PM |
|
THUMB.EXE |
4025198 |
3-14-97 |
5:27 PM |
|
THUMB.TXT |
3008 |
3-14-97 |
5:27 PM |
|
XNTBFS1.TXT |
2190 |
3-14-97 |
5:27 PM |
|
XNTBFS1.MSG |
424 |
3-14-97 |
5:27 PM |
NetBasic Sample - Find Network Address in NDS
Author: |
BA |
Document ID: |
TID101154 |
Date: |
3/14/97 5:25 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XNBTREE1.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
This NetBasic sample code demonstrates simple windowing and NDS lookup. It has the user log in to NDS, gets a servername, and finds the server's network address in NDS.
Detailed Description
This sample NetBasic script can be run on NetWare 4.11 by placing it in SYS:NETBASIC/USER.
Then at the console do the following:
LOAD NETBASIC |
|
RUN FINDADDR.BAS |
NDS user and other context information relative to [Root] must be entered to allow login. Then, the user enters a servername, and it does an NDS search to find the server's network address.
File Information
Self-Extracting File Name: XNBTREE1.EXE
Files Included: |
Size |
Date |
Time |
XNBTREE1.TXT |
(this file) |
||
FINDADDR.BAS |
4055 |
3-14-97 |
5:24 PM |
XNBTREE1.TXT |
2167 |
3-14-97 |
5:24 PM |
XNBTREE1.MSG |
172 |
3-14-97 |
5:24 PM |
SMSDF.TXT
Author: |
DJ |
Document ID: |
TID101158 |
Document revision: |
A |
Date: |
3/17/97 1:13 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
SMSDF.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
General Business |
Abstract
This TID describes various "DISK FULL" scenarios that can occur during restore.
File Information
Self-Extracting File Name: SMSDF.EXE
Files Included: |
Size |
Date |
Time |
SMSDF.TXT |
(this file) |
||
DISKFULL |
2315 |
3-11-97 |
12:08 PM |
Object Creation Demo with NDS ActiveX Control
Author: |
HW |
Document ID: |
TID101125 |
Document revision: |
A |
Date: |
3/6/97 5:12 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XCREATE.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
This sample creates objects of arbitrary classes using the DeveloperNet 2000 Directory control. For this sample to work, you should download the XSelect sample as well.
File Information
Self-Extracting File Name: XCREATE.EXE
Files Included: |
Size |
Date |
Time |
XCREATE.TXT |
(this file) |
||
FRMADDOB.FRM |
13304 |
3-3-97 |
5:14 PM |
README.TXT |
482 |
3-3-97 |
5:28 PM |
XCREATE.VBP |
900 |
3-3-97 |
5:14 PM |
XTRU2.TXT
Author: |
BA |
Document ID: |
TID101160 |
Document revision: |
A |
Date: |
3/17/97 1:20 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XTRU2.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
General Business |
Abstract
This sample NLM code demonstrates how to scan a directory for trustee rights.
File Information
Self-Extracting File Name: XTRU2.EXE
Files Included: |
Size |
Date |
Time |
XTRU2.TXT |
(this file) |
||
SCANTRUS.C |
7411 |
2-26-97 |
1:06 PM |
SCANTRUS.NLM |
2674 |
2-26-97 |
1:07 PM |
Novell NT Requester Does Not Provide a Diagnostic Responder
Author: |
DS |
Document ID: |
TID101168 |
Date: |
3/20/97 10:34 AM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
NTDIAGRQ.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
With the release of the 4.0 NetWare Requester for NT, customers have noticed that diagnostic applications no longer receive a response from their NT machines.
Detailed Description
When Novell designed the IntranetWare Client for Windows NT, it was decided that compatibility with existing NT services was of paramount importance. Because the specifications to tie into SMB (System Message Block) and RAS (Remote Asynch Server) are unpublished, it was not possible to build an IPX stack that would allow NT machines using a Novell Requester to participate in NT networks. For this reason, Novell decided to build a requester around Microsoft's NWLINK interface. This decision has a couple of drawbacks. One of those drawbacks is the fact that Novell no longer controls the IPX stack, so it is impossible to do some of the things we would have liked to do. Implementing an IPX Diagnostic Responder was one of these. Because we don't control the stack, we can't get many pieces of information out of it.
This was not an easy, nor particularly popular, decision, but it was necessary to provide customers with the level of heterogeneous functionality they expect. We have a couple of ideas on how we might get around this problem in the future, but we are unable at this time to speculate when that might be available.
File Information
Self-Extracting File Name: NTDIAGRQ.EXE
Files Included: |
Size |
Date |
Time |
NTDIAGRQ.TXT |
(this file) |
||
NTDIAGRQ.MSG |
163 |
3-20-97 |
10:34 AM |
Object Selector Sample for ActiveX Controls
Author: |
HW |
Document ID: |
TID101124 |
Document revision: |
A |
Date: |
3/6/97 5:10 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XSELECT.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
This sample implements an object selection tool for NDS with the look and feel of the Win95 common dialog controls. It allows you to browse and select objects in a specified tree and permits filtering by one or more object classes.
You may either use it as a reference for the DeveloperNet 2000 Directory control or exploit it as an OLE server to select objects from within your RAD program.
File Information
Self-Extracting File Name: XSELECT.EXE
Files Included: |
Size |
Date |
Time |
XSELECT.TXT |
(this file) |
||
EXPLORER.FRM |
14573 |
2-27-97 |
2:56 PM |
EXPLORER.FRX |
7559 |
2-27-97 |
2:56 PM |
MAIN.BAS |
1870 |
2-21-97 |
4:01 PM |
README.TXT |
562 |
2-21-97 |
3:58 PM |
SELECTOR.CLS |
3237 |
2-25-97 |
10:35 AM |
XSELECT.VBP |
789 |
2-25-97 |
3:04 PM |
ActiveX Directory Layouts
Author: |
HW |
Document ID: |
TID101123 |
Document revision: |
A |
Date: |
2/25/97 3:12 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XLAYOUT.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
This sample demonstrates the usage of the directory control to view layout and field information for all connected trees. It was written using Visual Basic 4, but should give you the idea how to it with any other RAD tool as well.
File Information
Self-Extracting File Name: XLAYOUT.EXE
Files Included: |
Size |
Date |
Time |
XLAYOUT.TXT |
(this file) |
||
README.TXT |
241 |
2-25-97 |
6:11 PM |
XLAYOUT.FRM |
14670 |
2-25-97 |
6:08 PM |
XLAYOUT.FRX |
1265 |
2-25-97 |
6:08 PM |
XLAYOUT.VBP |
859 |
2-25-97 |
6:07 PM |
ActiveX Session Control Demo
Author: |
HW |
Document ID: |
TID101121 |
Document revision: |
A |
Date: |
2/25/97 3:11 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XSESSION.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
This sample shows how to maintain connections and drive mappings using the new DeveloperNet2000 ActiveX controls and your favorite RAD tool.
It requires the Net2000 ActiveX controls for NDS.
Detailed Description
For a detailed description, please refer to the included readme.txt.
File Information
Self-Extracting File Name: XSESSION.EXE
Files Included: |
Size |
Date |
Time |
XSESSION.TXT |
(this file) |
||
DRIVE.FRM |
5047 |
2-21-97 |
3:04 PM |
DRIVE.FRX |
1090 |
2-21-97 |
3:04 PM |
MAIN.FRM |
17502 |
2-21-97 |
3:06 PM |
MAIN.FRX |
1596 |
2-21-97 |
3:06 PM |
README.TXT |
443 |
2-21-97 |
3:12 PM |
SESSIOND.VBP |
724 |
2-21-97 |
3:04 PM |
ActiveX Server Admin Control Demo
Author: |
HW |
Document ID: |
TID101122 |
Document revision: |
A |
Date: |
2/25/97 3:11 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XSERVMAN.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
This sample uses the DeveloperNet 2000 server administration control to maintain the settable configuration parameters on a NetWare server, load and unload NLMs, or run script files.
File Information
Self-Extracting File Name: XSERVMAN.EXE
Files Included: |
Size |
Date |
Time |
XSERVMAN.TXT |
(this file) |
||
FRMMAIN.FRM |
17882 |
2-25-97 |
9:48 AM |
FRMMAIN.FRX |
506 |
2-25-97 |
9:48 AM |
README.TXT |
703 |
2-25-97 |
10:18 AM |
XSERVMAN.VBP |
963 |
2-25-97 |
9:48 AM |
NetWare Telephony Private Data Negotiation
Author: |
SP |
Document ID: |
TID101120 |
Document revision: |
A |
Date: |
2/25/97 3:10 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
PRIVATE.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
This sample code illustrates the use of private data with the AT&T G3 switch.
File Information
Self-Extracting File Name: PRIVATE.EXE
Files Included: |
Size |
Date |
Time |
PRIVATE.TXT |
(this file) |
||
PRIVATE.C |
18181 |
1-7-97 |
11:46 AM |
Tool: Java Rdebug-Remote Source Level Debugger
Author: |
RK |
Document ID: |
TID101174 |
Date: |
3/21/97 4:31 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
TRDBRK01.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
This TID treats the pre-release remote source level debugger for the NetWare server environment (NLM) written in Java.
Detailed Description
Readme for Rdebug
The latest version of Rdebug was written specifically for debugging the NetWare server environment. Like previous versions of Rdebug, it debugs NLMs remotely. It was written in Java so that it will run on many different platforms.
Rdebug Server Setup
To use Rdebug 3.0 with Green River servers, the RDEBUG.NLM file must be located in the target server. (On releases after Green River, RDEBUG.NLM will not be needed on the server.) This is not the same RDEBUG.NLM that was used with previous versions of Rdebug, however the debugger will run with previous versions of RDEBUG.NLM-- in a limited fashion. Previous versions of Rdebug client will run with the new RDEBUG.NLM. The RDEBUG configuration file can also be used and must be located in the target server's boot directory on the DOS partition.
Communication between the Rdebug host system and the target server can take place through either a serial cable or Ethernet as explained in the sections below.
Client Setup
To run Rdebug 3.0:
1. |
You must have Java installed on your client machine. You candownload Java fromhttp://java.sun.com. You must download the 1.0.2 JDK, not the latest version of the 1.1JDK. |
2. |
Unzip the files from the Rdebug30 zip file. These have been zipped withWinzip topreserve the case and long filenames. CASE IS VERY IMPORTANT! The files are notin DOS 8.3 format, and should not be unzipped with any version of PKZIP or other ziputilities that do not preserve case and long names. |
The zip filecontains the following files: |
||
env.bat |
||
ndiapi.dll |
||
RDEBUG.NLM |
||
rdebug.zip |
||
RdebugApp.class |
||
rdebuglg.gif |
||
readme.txt |
||
run.bat |
Copy these files to a directory named COM\novell\rdebug onyour client machine. |
Note: It is NOT necessary, nor desirable to unzip the Rdebug.zipfile.
3. |
In a Windows 95 or Windows NT DOS Box, set the path toinclude<DRIVE<:\java\bin, and set an environment variable called CLASSPATH to<DRIVE<:\java\lib;<DRIVE<:\;<DRIVE<:\COM \novell\rdebug;<DRIVE<:\COM\novell\rdebug \Rdebug.zip, where drive represents theproper drive for the Java JDK, and the proper drive for the Rdebug files. |
4. |
Change to the COM\novell\rdebug directory (cd\COM\novell\rdebug). |
5. |
Start Rdebug by issuing the "java RdebugApp" command. (Note that unlikepreviousversions of Rdebug, the target server does not need to be setup and ready to go at thispoint.) |
Note: If you are using Windows 95 or Windows NT, an alternate tostep 4 and 5 is to createa shortcut that runs \java\bin\java.exe and passes it RdebugApp as a parameter. It muststart in the COM\novell\rdebug directory.
Using the Ethernet Interface
The Sun Java 1.0.x JDK has a bug in it that prevents the use of the Ethernet interface. If you are using Symantec Cafe for your JDK, you can use Ethernet; otherwise you must use serial. The bug has been fixed in the 1.1 JDK, however, this JDK is incompatible with 1.0 and with other versions of the Java Virtual Machine. When this version of JDK becomes more widely accepted, Rdebug will be changed to use it.
The Ethernet interface uses the UDP/IP transport protocol. Routing is supported by using ARP. To use the Ethernet interface, you must have 2 IP addresses, one for the server and one for the workstation.
You need an NE2000 board in your server. At the moment, the NE2000 is the only Ethernet card that is supported. This card should be in addition to the LAN card that is used by your server for regular network communication. It is possible to debug using a single NE2000 in the server. In such a case however, the debugger will take over the NE2000 card and the NetWare Server will not have access to the card.
RDEBUG.NLM is invoked from the NetWare Internal Debugger. Thus, after loading RDEBUG.NLM, you should break into the Internal Debugger by pressing SHIFT, SHIFT, ALT, ESC. Then invoke Rdebug with the appropriate command line. An example would be:
#Rdebug NE2000 IP 111.222.333.444port=320 |
Parameter information can be obtained by typing "rdebug help" from within the NetWare Internal Debugger.
If you don't want to type in the IP address every time you invoke the debugger, you can put it in a file on the DOS partition in the boot directory. The file is named RDEBUG.CFG and should contain only one line in the file, with the following format:
NE2000 IP <ip address< port=<portnumber< |
for example:
NE2000 IP 111.222.333.444 port=320 |
Note that port is the port address of the NE2000 card you are using for the debugger.
No LAN driver should be loaded by the server for the NE2000 card that will be used by the debugger. RDEBUG.NLM contains a special NE2000 driver that will control the additional LAN card.
Using a Serial Interface
If you want to use the serial interface, you must have a serial cable between the server and the workstation.
For the Workstation
The debugger defaults to COM1. However, you may override this by specifying the COM port in the Options dialog from the initial Rdebug window "Settings" menu.
For the Server
If you are not using COM1, you may either type the port as part of the command to invoke RDEBUG, as in
#RDEBUG COM2 |
or put it in the RDEBUG.CFG file. This file is on the DOS partition in the boot directory. It should only have one line in the file, with the following format:
COM2 |
The RDEBUG.CFG File
As was previously mentioned, this file contains only one line, which specifies the option most commonly used. It is possible, however, to create a configuration file that will allow the use of either option. To do this, create an RDEBUG.CFG file that has the format:
COMPort NE2000 IP <IP address<port=<port< |
When you invoke Rdebug from the Internal Debugger, it will by default use the Ethernet driver. However, to use the serial port driver, you merely invoke it with a "serial" option, as follows:
#Rdebug serial |
General Notes
Each symbol file is parsed and loaded entirely into memory in its parsed format. This implies of course, that the more NLMs you debug, the more memory it takes. If you have a machine with limited memory (under 24 megabytes), you will obtain better performance by closing down unneeded applications. Debugging NLMs with minimal-sized symbol files presents few, if any, problems. However, debugging multiple NLMs, or NLMS with extremely large symbol files (over 1 megabyte), will cause noticeable performance degradation on machines with limited memory.
Because the Java Virtual Machine relies on the underlying operating system to handle all memory management, performance on a slow machine can be improved by better management of virtual memory according to the rules enforced by that particular operating system.
Simply stated, the performance of the debugger is directly proportional to the amount of free memory on your machine.
File Information
Self-Extracting File Name: TRDBRK01.EXE
Files Included: |
Size |
Date |
Time |
TRDBRK01.TXT |
(this file) |
||
RDEBUG30.ZIP |
1206944 |
3-21-97 |
4:22 PM |
TRDBRK01.MSG |
100 |
3-21-97 |
4:22 PM |
IMISC02.TXT
Author: |
BA |
Document ID: |
TID101159 |
Document revision: |
A |
Date: |
3/17/97 1:17 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
IMISC02.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
General Business |
Abstract
Some differences between Watcom 10.6 and 11 are noteworthy when building NLMs. There are two fundamental differences between the two versions:
A new linker switch that seems to cause problems on some development platforms
A structure alignment default change from 1 byte aligned to 4 byte aligned
Detailed Description
Two items to be aware of when moving from Watcom 10.6 to Watcom 11 are as follows:
1. |
In the IDE, a new linker option "Incremental Linking[op inc]" is turned on by default.This feature has been known to make WLINK appear to be in an endless loop, nevercompleting the link operation. This option should be disabled in the IDE by doing thefollowing: |
|
a. |
In the Options menu, choose "Link For NetWareSwitches...." |
|
b. |
Uncheck the "Incremental Linking [op inc]" option |
|
2. |
The compiler structure alignment has changed from a default of 1byte alignment [-zp1]to a default of 4 bytes [-zp4]. |
|
Because the default in Watcom 10.6 was 1 byte alignment, nospecial compiler optionsfor structure packing was ever specified in the makefiles. However, in order to buildNLMs in Watcom 11, you must specify the 1 byte alignment option [-zp1] in yourmakefile for compiler options. |
||
In the IDE, do the following to accomplish this change: |
||
a. |
In the Options menu, choose "C Compiler Switches..." |
|
b. |
Click the >> button until you get to page 3 "Source Switches" |
|
c. |
Click the radio button for "1 byte alignment[-zp1]" |
File Information
Self-Extracting File Name: IMISC02.EXE
Files Included: |
Size |
Date |
Time |
IMISC02.TXT |
(this file) |
Revised sendBLk.c Sample Code
Author: |
MM |
Document ID: |
TID101119 |
Document revision: |
A |
Date: |
2/25/97 3:10 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
NWSIPXSB.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK 1.0e |
Category: |
General Business |
Abstract
SDK release 10 sendblk.c sample code hangs if the receiving machine is a very fast machine because the sample code posts the listening for disconnect after sending all the messages. So NWSipxRegisterForTransportEvent should be called with a separate disconnect TCB right after NWSipxOpenConnectionEndpoint. The revised sendblk.c is attached in this TID.
File Information
Self-Extracting File Name: NWSIPXSB.EXE
Files Included: |
Size |
Date |
Time |
NWSIPXSB.TXT |
(this file) |
||
SENDBLK.CPP |
10727 |
2-7-97 |
10:14 AM |
NWSIPX Requirements for Proper SPX Session Termination
Author: |
DS |
Document ID: |
TID101169 |
Date: |
3/20/97 10:36 AM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
SIPXTERM.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
The following document describes requirements for properly terminating SPX sessions in NWSIPX. It talks about some of the less intuitive things you need to know if you use NWSIPX.
Detailed Description
To terminate an SPX session in NWSIPX, you call NWSipxTerminateConnection. When you call this, you will specify SIPX_TERM_ACKED, or SIPX_TERM_ABORT. If you specify ABORT, SIPX will attempt to kill the session immediately, regardless of whether the other workstation acknowledges the termination. If you specify SIPX_TERM_ACKED, however, NWSIPX will wait until the other workstation acknowledges the termination before completing the posted NWTCB. If the NWTCB has a notification type of SIPX_API_EVENT, for example, the call to terminate will return immediately, but the TCB status will be SIPX_PENDING until the termination is acknowledged.
There is some confusion when making calls to terminate the connection, just exactly who should acknowledge the termination. Is this the job of the application or the API? The answer is both. The user program does not have to physically acknowledge the termination event, but it does have to allocate and post a receive on an NWTCB so that the termination can be acknowledged. This too causes some confusion. Typically, the developer will allocate a TCB, set the TCBTransportEvent field to SIPX_LISTEN_FOR_DISCONNECT, and call NWSipxListenForTransportEvent, as is demonstrated below.
sipxCode =NWSipxAllocControlBlock(SIPX_API_EVENT,NULL,&pTerminateTcb); |
|
pTerminateTcb->TCBTransportEvent =SIPX_LISTEN_FOR_DISCONNECT; |
|
pTerminateTcb->TCBFlags = 0; |
|
pTerminateTcb->TCBConnHandle = connection; |
|
sipxCode =NWSipxRegisterForTransportEvent(pTerminateTcb); |
This code can be used to notify you of when a termination event has occurred and was acknowledged, but it cannot be used to actually acknowledge a termination request. For that, you must allocate a second TCB, and call NWSipxReceiveMessage. You don't have to ever look at the packet, or do anything with it, but it must be posted.
There are a couple of exceptions to this rule. The Windows NT requester will buffer incoming packets. Because it does this, the second TCB does not need to be posted. Future revisions of Client 32 For Windows 95 will also contain this functionality. In order to preserve backwards compatibility, and ensure that your application does not hang upon a termination attempt, you will always want to make sure that you have at least one receive packet posted at all times.
File Information
Self-Extracting File Name: SIPXTERM.EXE
Files Included: |
Size |
Date |
Time |
SIPXTERM.TXT |
(this file) |
||
SIPXTERM.MSG |
182 |
3-20-97 |
10:36 AM |
NetBasic Web NDS Browser Demo
Author: |
BA |
Document ID: |
TID101156 |
Date: |
3/14/97 5:31 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
XNTBNDS1.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
None |
Abstract
NetBasic for the Internet NDS Browser Demo for the Web
This NetBasic script demonstrates several NetBasic NMX NDS APIs. It is an NDS Browser accessible from the Web, running on NetWare 4.11 (IntranetWare) with the NetWare Web Server 2.51 or above.
File Information
Self-Extracting File Name: XNTBNDS1.EXE
Files Included: |
Size |
Date |
Time |
XNTBNDS1.TXT |
(this file) |
||
NDS.BAS |
18282 |
3-14-97 |
5:28 PM |
NDS.TXT |
782 |
3-14-97 |
5:28 PM |
XNTBNDS1.TXT |
1904 |
3-14-97 |
5:28 PM |
XNTBNDS1.MSG |
264 |
3-14-97 |
5:28 PM |
SMSNTTSA.TXT
Author: |
DJ |
Document ID: |
TID101157 |
Document revision: |
A |
Date: |
3/17/97 1:11 PM |
Alert status: |
Yellow |
Information type: |
Issue |
Readme for: |
SMSNTTSA.EXE |
Novell product class: |
NetWare API |
Novell product andversion: |
NetWare SDK |
Category: |
General Business |
Abstract
Attached is a zip file containing the beta release of the Windows NT TSA, along with 2 text files which describe installation and usage. We are interested in your feedback on this beta product. You can send your comments to devsup@novell.com.
File Information
Self-Extracting File Name: SMSNTTSA.EXE
Files Included: |
Size |
Date |
Time |
SMSNTTSA.TXT |
(this file) |
||
NTTSA.ZIP |
250159 |
2-11-97 |
2:01 PM |
RELEASE.TXT |
2155 |
1-30-97 |
2:44 PM |
TSA-USR.TXT |
6091 |
1-30-97 |
10:18 AM |
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.