Developer Pointers
Articles and Tips: article
01 May 1998
Novell Technical Information Documents
All of the Technical Information Documents (TIDs) discussed below are available at thefollowing 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)
Increasing the Limitation of FD_SETSIZE for select()
|
Author: |
EE |
|
Document ID: |
TID101549 |
|
Date: |
4/2/98 5:24 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
DBSDE002.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
This document discussed how to increase the FD_SETSIZE limitation of 16. The sample code of how to accomplish this can be found at the end of the document.
Detailed Description
This document shows how to increase the limitation of FD_SETSIZE from 16 to a higher number.
Problem and History Novell Developer Technical Support reports a high activity in porting UNIX applications to NetWare as NetWare Loadable modules (NLMs), requesting that FD_SETSIZE be bumped to a higher number asserting that 16 asynchronous connections constitute too small a limit for them. This limit figures in the server library, NLMLIB.NLM.
Work-Around There is a way to work around this limitation, notably by launching a new thread for each set of 16 sockets. However, a separate stack must be allocated for each new thread begun.
Impediment to the Obvious Solution The principal impediment to bumping the value of FD_SETSIZE arbitrarily is one of backward compatibility. One weakness of the sockets interface which we cannot changeis that function select()operates on three fd_setsof length determined by FD_SETSIZE rather than a length argument unfortunately. With all existing NLM binaries built with fd_sets containing fd_arraysdimensioned by FD_SETSIZEas 16, nothing can be done to increase FD_SETSIZE in NLMLIB.NLM without compromising memory integrity dramatically because underneath select(), variables of type fd_setare zero-filled to length FD_SETSIZE.
A new call was added to the library, Set_FD_SETSIZE(size_t), that increases, for the calling thread only, the size of the fd_arrayand hence fd_set for all affected calls made by that thread. The argument, size_t, which is an unsigned int, can specify a lot more than 16.
Solution Setting and Availability The default size of the array passed will remain at 16 to accommodate (and protect from abend) all older binaries. Note that, if you wish to code an NLM that will run on all versions of CLIB, you will need to import the new interface dynamically. Included at the end of this document is sample code to illustrate this.
The solution is visible to the developer in sys/types.h where the following definitions and prototype will appear close to where FD_SETSIZEis defined:
typedef long dyn_fd_array[1];
typedef struct dyn_fd_set
{
dyn_fd_array fds;
} dyn_fd_set;
extern size_t Set_FD_SETSIZE( size_t new_fd_setsize );
/* returns most recent size */
There is no need for new versions of any of the functions originally created to support the earlier, compile-time solution since select(), bsd_select(), bsd_fd_set (), bsd_fd_clr () and bsd_fd_isset() will simply check the calling thread's globals (TCS) for an fd_setsize different from 16 and follow that. It is, therefore, incumbent on the caller that the value passed to Set_FD_SETSIZE()and the actual size of the fd_set passed to the Sockets functions be identical. Failure to remain at parity in these will certainly cause abnormal termination of NetWare.
Impact on the Existing Product To waken this capability, the new interface must be called. Otherwise, the original limit of 16 remains in force and no fd_setcan be smaller than that.
Documentation Issues Strictly speaking, no interface changes to normal sockets programming concepts result from this implementation. However, the pointer passed to arguments of type fd_set * will need casting (from dyn_fd_set*).
Additional Notes Header sys/sockio.h is not affected by any of these changes nor by inclusion order. It is not necessary to link with NWPRE.OBJ to get this new functionality; indeed, if the application is to work also under older versions of CLIB.NLM, it must be linked with Prelude.Obj. This also bars it from gaining the new, full ANSI compliance of the new library affecting the behavior of fputsand the scanf- family of functions as well as from getting the new, more UNIX-like command line redirection. Usually, these issues are of minor or no importance.
Sample Code This implementation has been set up to demonstrate code that would also work with an older version of CLIB.NLM that doesn't support a dynamic FD_SETSIZE. This code has neither been compiled nor tested. It is only provided as a starting point for using the new dynamic FD_SETSIZE functionality. When using new SDK headers like nwadv.h instead of advanced.h to write code that is going to run on older versions of CLIB.NLM, some attention to backward compatibility is necessary. Notably, Prelude.Obj must be used and not the newer NWPRE.OBJ. Other considerations exceed the scope of this document.
/*****************************************/
#include /* whence malloc() */
#include
#include
#include
#include
#include /* used to be advanced.hwhence ImportSymbol() */
#include /* used to be process.hwhence GetNLMHandle() */
#define MY_FD_SETSIZE 256 /* Can be a value greater than 256 */
/*
** If this function exists, then the library supports using more
** descriptors than FD_SETSIZE.
*/
size_t (*Set_FD_SETSIZE)( size_t );
int MultiSelectFunc( void )
{
int numfds, ourNLM;
size_t newSize, oldSize;
dyn_fd_set *rfds, *wfds, *exfds;
struct timeval t;
ourNLM = GetNLMHandle();
/*
** Instead of using Set_FD_SETSIZE() directly--and becoming load-
** dependent on this function, we import it dynamically and, if
** it is there, know that we can use 256 sockets instead of only
** 16. The size change only affects this thread, however. The new
** size is set in state information held by this thread's control
** structure and used in place of the manifest constant FD_SETSIZE.
*/
Set_FD_SETSIZE = ImportSymbol(ourNLM, "Set_FD_SETSIZE");
if (Set_FD_SETSIZE)
oldSize = *Set_FD_SETSIZE)(newSize = MY_FD_SETSIZE);
else
newSize = oldSize = FD_SETSIZE;
rdfs = (dyn_fd_set *) malloc(newSize * sizeof(long));
wdfs = (dyn_fd_set *) malloc(newSize * sizeof(long));
exdfs = (dyn_fd_set *) malloc(newSize * sizeof(long));
if (!rdfs || !wfds || !exfds)
goto ErrorExit;
/* because FD_ZERO(), anchored to FD_SETSIZE as it is,
won't work here!!!!! */
memset(rdfs, 0, newSize * sizeof(long));
memset(wdfs, 0, newSize * sizeof(long));
memset(exdfs, 0, newSize * sizeof(long));
numfds = 0;
while (numfds < newSize)
{
/* fill the arrays with whatever; FD_SET, FD_ISSET
and FD_CLR do work...*/
numfds++;
}
t.tv_sec = 10L;
t.tv_usec = 0L;
select(numfds, (fd_set *) rfds, (fd_set *)
wfds, (fd_set *) exfds, &t);&
/* etc. */
ErrorExit :
if (rdfs)
free(rdfs);
if (wfds)
free(wdfs);
if (exfds)
free(exdfs);
/* we no longer depend on this symbol once unloaded */
if (Set_FD_SETSIZE)
UnimportSymbol(ourNLM, "Set_FD_SETSIZE");
}
File Information
Self-Extracting File Name: DBSDE002.EXE
|
Files Included: |
Size |
Date |
Time |
|
DBSDE002.TXT |
(this file) |
||
|
DBSDE002.MSG |
153 |
4-2-98 |
5:24 PM |
|
DBSDE002.TXT |
8354 |
4-2-98 |
5:24 PM |
JNDI Samples To List Context, Read dirContext, and createSubContext
|
Author: |
MM |
|
Document ID: |
TID101542 |
|
Date: |
3/30/98 3:10 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
XMMJNDI.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
The following three JNDI sample codes will use Java Naming and Directory Interface (JNDI) to list objects in a context, read some or all attributes of an NDS object, and add an OU and an NDS user to that OU.
Detailed Description
JNDIListObjs.java This sample code lists a context. Use JNDI to list objects in a context. It will list objects under NetWare namespace. It depends on how users specify the context. It can list objects in different namespaces such as NDS, bindery, NCP extension, or NetWare file system.
JNDIGetattrs.java This sample code reads a DirContext. Use JNDI to get some or all attributes of an NDS object.
JNDICreateSubctx.java This sample code creates an NDS organizational unit (OU) and creates a user under that newly created OU. Delete the two NDS objects if desired.
File Information
Self-Extracting File Name: XMMJNDI.EXE
|
Files Included: |
Size |
Date |
Time |
|
XMMJNDI.TXT |
(this file) |
||
|
JNDICODE.EXE |
35714 |
3-30-98 |
3:10 PM |
|
XMMJNDI.MSG |
207 |
3-30-98 |
3:10 PM |
SACReadSNMPObject Returns SysUpTime in System Time
|
Author: |
SP |
|
Document ID: |
TID101540 |
|
Date: |
3/17/98 6:55 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
XSNMPS01.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
There can be confusion when reading the time returned for SysUpTimefrom SACReadSNMPObject.
Detailed Description
Using SACReadSNMPObject()to get a sysUpTime value 1.3.6.1.2.1.1.3 returns the timeticks in system time (18.2/second) instead of converting it to ASN_TIMETICKS (10 ms). Therefore, the value seems to disagree with that returned through an SNMP PDU request.You can convert the value, as per sysuptime.c.
File Information
Self-Extracting File Name: XSNMPS01.EXE
|
Files Included: |
Size |
Date |
Time |
|
XSNMPS01.TXT |
(this file) |
||
|
SYSUP.C |
5222 |
3-17-98 |
6:55 PM |
|
XSNMPS01.MSG |
79 |
3-17-98 |
6:55 PM |
New Files for Snap-ins that Use the MFC Snap-In Architecture
|
Author: |
MM |
|
Document ID: |
TID101547 |
|
Date: |
4/1/98 10:29 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
IMMSNAP.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
If you have a Snap-in that uses the MFC Snap-in architecture, use the attached three files (MfcSnapIn.h, CppSnapIn.h, CppSnapIn.cpp) instead of the ones from the SDK. This allows you to use MFC in a Shared DLL.
Detailed Description
If you have a Snap-in that uses the MFC Snap-in architecture, use the attached three files (MfcSnapIn.h, CppSnapIn.h, CppSnapIn.cpp) instead of the ones from the SDK. This allows you to use MFC in a Shared DLL. The change has to do with the module state information getting confused when called from a non-MFC Application. A call to AFX_MANAGE_STATE at all the entry points is added if the module is built using MFC in a Shared DLL. After making the file switch, just make the change to Use MFC in a Shared DLL in the General page of Project Settings. Then rebuild the entire project.
File Information
Self-Extracting File Name: IMMSNAP.EXE
|
Files Included: |
Size |
Date |
Time |
|
IMMSNAP.TXT |
(this file) |
||
|
CPPSNPIN.CPP |
56422 |
4-1-98 |
10:29 AM |
|
CPPSNPIN.H |
17978 |
4-1-98 |
10:29 AM |
|
MFCSNPIN.H |
5335 |
4-1-98 |
10:29 AM |
|
IMMSNAP.MSG |
213 |
4-1-98 |
10:29 AM |
Telephony Applications on NetWare Fail To Build with Watcom 11
|
Author: |
SP |
|
Document ID: |
TID101546 |
|
Date: |
3/31/98 5:44 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
ITELS004.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
Using Watcom 11 will cause problems during compilation as it reads acs.h.
Detailed Description
In an NLM build environment, Watcom 11 defines _WIN32 which is used by TSPLATFM.H to determine the Windows platform. This causes problems since TSPLATFM.H can't then distinguish Windows platform from NetWare NLM platform.
To correct the problem, replace \TELEPHON\SDK\HDRS\TSPLATFM.H with the attached version, and include "#define N_PLAT_NLM" prior to the header list. By default, if you use QMK386, this definition will be in your MAKEFILE. Otherwise, it can be included in the .C file.
File Information
Self-Extracting File Name: ITELS004.EXE
|
Files Included: |
Size |
Date |
Time |
|
ITELS004.TXT |
(this file) |
||
|
TSPLATFM.H |
3001 |
3-31-98 |
5:44 PM |
|
ITELS004.MSG |
74 |
3-31-98 |
5:44 PM |
Sample To Demonstrate Walking the Server Connection Table
|
Author: |
SP |
|
Document ID: |
TID101545 |
|
Date: |
3/31/98 2:06 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
XNLMSP03.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
CONN.C walks the connection table of a NetWare 4.11 server using the cross-platform APIs. It uses TLI to send a watchdog packet to each client in the table.
Detailed Description
CONN.C walks the connection table of a NetWare 4.11 server using the cross-platform APIs. It uses TLI to send a watchdog packet to each client in the table. An authenticated connection is required in order to get this information, even from the server platform.
Note that DSAPI.NLM from Support Pack 5 or later is required.
File Information
Self-Extracting File Name: XNLMSP03.EXE
|
Files Included: |
Size |
Date |
Time |
|
XNLMSP03.TXT |
(this file) |
||
|
CONN.C |
11519 |
3-31-98 |
2:06 PM |
|
XNLMSP03.MSG |
159 |
3-31-98 |
2:06 PM |
AddressBook Control Example for Delphi 3
|
Author: |
RL |
|
Document ID: |
TID101538 |
|
Date: |
3/16/98 1:34 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
GW5XAB02.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
This is an updated sample for Delphi 3 that shows how to use the AddressBook Control. The library name that is imported between Delphi 2 and Delphi 3 changed if you use the default OCX import.
File Information
Self-Extracting File Name: GW5XAB02.EXE
|
Files Included: |
Size |
Date |
Time |
|
GW5XAB02.TXT |
(this file) |
||
|
ABK.PAS |
650 |
3-16-98 |
1:33 PM |
|
ABK.DFM |
519 |
3-16-98 |
1:33 PM |
|
ABKSAMP.DPR |
183 |
3-16-98 |
1:33 PM |
|
ABKSAMP.EXE |
243200 |
3-16-98 |
1:33 PM |
|
GW5XAB02.MSG |
195 |
3-16-98 |
1:33 PM |
SPX to SPX II Communications
|
Author: |
EE |
|
Document ID: |
TID101541 |
|
Date: |
3/18/98 11:48 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
ISPXE002.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
SPX/SPX II communications involve either the Client end using SPX II and the Host end using SPX or vice versa. In these scenarios, the SPX II end "falls back" to the SPX connection protocol.
Detailed Description
SPX/SPX II communications involve either the Client end using SPX II and the Host end using SPX or vice versa. In these scenarios, the SPX II end "falls back" to the SPX connection protocol.
Connection Control Field Values Two additional definitions in the Connection Control field enable SPX II clients to negotiate size and indicate that the communication is SPX or SPX II based:
Value Name Description 0x04 NEG/SIZ Negotiate size request/response 0x08 SPX2 SPX II type packet
SPX II Client to SPX Host Assuming a normal SPX II to SPX connection, the Client issues an SPX II Connection Request with the NEG and SPX2 bits set. The Host ignores the NEG and SPX2 bits and returns a standard SPX Connection Ack. At this point the Client recognizes that the partner did not set the SPX2 bit in the Connection Ack and "falls back" to the standard SPX connection protocol.
SPX Client to SPX II Host Assuming a normal SPX to SPX II connection, the Client issues an SPX Connection Request with the NEG and SPX2 bits clear. The Host recognizes that the NEG and SPX2 bits are not set and returns a standard SPX Connection Ack and "falls back" to the standard SPX connection protocol.
File Information
Self-Extracting File Name: ISPXE002.EXE
|
Files Included: |
Size |
Date |
Time |
|
ISPXE002.TXT |
(this file) |
||
|
ISPXE002.MSG |
192 |
3-18-98 |
11:48 AM |
Design Limitation of NWSIPX Multiplexed API-managed Events Method
|
Author: |
EE |
|
Document ID: |
TID101548 |
|
Date: |
4/1/98 2:23 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
ISPXE003.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
There is a design limitation of 64 mux groups with NWSIPX Multiplexed API-managed Events method. Exceeding this limitation will result in error SIPX_INSUFFICIENT_RESOURCES (0x80000007)when calling NWSIPXAllocControlBlock.
Detailed Description
There is a design limitation of 64 mux groups with NWSIPX Multiplexed API-managed Events method. Details of Multiplexed API-managed events (SIPX_API_MUX_EVENT) are documented in the SDK. This method of event notification allows you to monitor multiple NWTCBs for event completion with a single call to NWSipxWaitForMultipleEvents. To group NWTCBs for use by NWSipxWaitForMultipleEvents, an NWTCB mux group must be created and the mux group handle specified when allocating the NWTCB. A new NWTCB mux group is automatically created by the NWSIPX API whenever a mux group handle value of SIPX_ALLOC_MUX_GROUPis passed to NWSIPXAllocControlBlock.
The following demonstrates how one might run into the 64 mux groups limitation and receive an error like SIPX_INSUFFICIENT_RESOURCES:
/* Global variable */
SIPXMUXGRP_HANDLE RcvMuxGroup; //
Handle to the mux group,
// not initialized
main ()
{
...
/* Initialize handle to mux group locally */
RcvMuxGroup = SIPX_ALLOC_MUX_GROUP;
/* A new mux group gets created everytime
NWSipxAllocControlBlock() is called */
for (i=1; i < NumOfIterations; i++)
{
...
NWSipxAllocControlBlock(SIPX_API_MUX_EVENT,
&RcvMuxGroup, &ptcb);&
...
}
}
If NumOfIterations is greater than 65, at the 65th iteration, the call to NWSipxAllocControlBlock()will fail and return SIPX_INSUFFICIENT_RESOURCES (0x80000007). This is because RcvMuxGroup gets assigned with SIPX_ALLOC_MUX_GROUP 65 times. As mentioned above, 64 NWTCB mux groups get created, and due to the design limitation, the 65th attempt failed.
To correct this problem, initialize the mux group handle globally:
/* Global*/
SIPXMUXGRP_HANDLE RcvMuxGroup =
SIPX_ALLOC_MUX_GROUP;
main ()
{
...
/* Now, the same handle is used everytime
NWSipxAllocControlBlock() is called */
for (i=1; i < NumOfIterations; i++)
{
...
NWSipxAllocControlBlock(SIPX_API_MUX_EVENT,
&RcvMuxGroup, &ptcb);&
...
}
}
File Information
Self-Extracting File Name: ISPXE003.EXE
|
Files Included: |
Size |
Date |
Time |
|
ISPXE003.TXT |
(this file) |
||
|
ISPXE003.TXT |
3944 |
4-1-98 |
2:22 PM |
|
ISPXE003.MSG |
223 |
4-1-98 |
2:22 PM |
Sample: NCP Extensions with Delphi Client
|
Author: |
WS |
|
Document ID: |
TID101539 |
|
Date: |
3/17/98 9:50 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
DNCPEXT.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
DNCPExt1 is a Delphi 2.x/3.x and an NLM application that illustrates the use of NCP extensions with a Windows client written in Delphi. This client-server application shows how to make use of NCP extensions to access NetWare functions that otherwise would not be available to clients. In this sample, NCP extensions allow you to retrieve and access the server screen, and to grant trustee rights to yourself.
Detailed Description
DNCPExt1 is a Delphi 2.x/3.x and an NLM application that illustrates the use of NCP extensions with a Windows client written in Delphi. This client-server application shows how to make use of NCP extensions to access NetWare functions that otherwise would not be available to clients. In this sample, NCP extensions allow you to retrieve and access the server screen, and to grant trustee rights to yourself.
The NCP extensions require that an NCP handler NLM is loaded at the selected target server. The NCP handler for this sample is WSEXT.NLM, which is provided with source code.
General information on how to use Delphi with the NetWare SDK can be found in the HOW-TO.DOC file.
To run the application, you need access to the 32-bit NetWare DLLs as provided in the NetWare Client32.
Platform Client: Windows, Windows 95, or Windows NT (tested on Windows 95) Server: NetWare v3.2, v4.x, or v5.x (tested on v4.11)
Compilers Client: Borland Delphi 2.x/3.x Server: Watcom C with Novell include files and libraries
Functions Used DNCPExt1 demonstrates the following NetWare API functions:
NWCallsInitNWCCGetPrimConnRef
NWCCOpenConnByRef
NWCCScanConnRefs
NWDSGetBinderyContext
NWDSGetServerDN
NWGetFileServerInformation
NWGetNCPExtensionInfoByName
WInitUnicodeTables
NWNCPExtensionRequest
NWScanNCPExtensions
NWSMLoadNLM
NWSMUnloadNLM
WSEXT demonstrates the following NetWare API functions:
AddTrusteeGetConnectionInformation
NWRegisterNCPExtension
NWDeRegisterNCPExtension
SetCurrentScreen
Included Files:
|
READ.ME |
This file |
|
HOW-TO.DOC |
General info about Delphi client development |
|
NWADMIN.ICO |
NetWare icon |
|
DELPHI_U.PAS |
Client: Helper function library |
|
DNCPExt1.dpr |
Client: Delphi Project |
|
DNCPEXT1.EXE |
Client: Executable |
|
DNCPExt1.res |
Client: Resource file |
|
main.dfm |
Client: Main form |
|
main.pas |
Client: Main source |
|
NCP_Ext.pas |
Client: NCP function library |
|
u_vars.pas |
Client: Helper vars/functions |
|
MAKEFILE |
|
|
MAKEINIT |
|
|
WSEXT.C |
Server: Source |
|
WSEXT.NLM |
Server: Executable |
File Information
Self-Extracting File Name: DNCPEXT.EXE
|
Files Included: |
Size |
Date |
Time |
|
DNCPEXT.TXT |
(this file) |
||
|
DNCPEXT1.EXE |
263680 |
3-17-98 |
9:49 AM |
|
DELPHI_U.PAS |
39268 |
3-17-98 |
9:49 AM |
|
MAIN.PAS |
19921 |
3-17-98 |
9:49 AM |
|
WSEXT.NLM |
19314 |
3-17-98 |
9:49 AM |
|
WSEXT.C |
15769 |
3-17-98 |
9:49 AM |
|
NCP_EXT.PAS |
13076 |
3-17-98 |
9:49 AM |
|
MAIN.DFM |
9269 |
3-17-98 |
9:49 AM |
|
HOW-TO.DOC |
5958 |
3-17-98 |
9:49 AM |
|
MAKEINIT |
3906 |
3-17-98 |
9:49 AM |
|
DNCPEXT1.DSK |
3343 |
3-17-98 |
9:49 AM |
|
MAKEFILE |
3255 |
3-17-98 |
9:49 AM |
|
READ.ME |
2086 |
3-17-98 |
9:49 AM |
|
U_VARS.PAS |
1445 |
3-17-98 |
9:49 AM |
|
DNCPEXT1.RES |
876 |
3-17-98 |
9:49 AM |
|
NWADMIN.ICO |
766 |
3-17-98 |
9:49 AM |
|
DNCPEXT1.DOF |
565 |
3-17-98 |
9:49 AM |
|
DNCPEXT1.DPR |
255 |
3-17-98 |
9:49 AM |
|
DNCPEXT.MSG |
414 |
3-17-98 |
9:49 AM |
Disabling Nagle Algorithm for TCPIP Socket and/or TLI Interface
|
Author: |
SP |
|
Document ID: |
TID101534 |
|
Date: |
3/10/98 9:33 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
IBSDS003.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
TCPIP.NLM version 3.1 enables the Nagle Algorithm by default. This document includes code to disable the function per socket. This feature is introduced in the TLI interface for TCPIP in the post 4.0 version of TCPIP.NLM. The TLI interface is also included. Attached is a TLI echo server with Nagle disabled.
Detailed Description
In TCPIP version 3.1 the Nagle Algorithm is enabled by default, but you can disable it for individual sockets by using setsockopt()with the TCP_NODELAY option as shown below. The Nagle Algorithm prevents excessive bandwith utilization by applications that send many small packets. It allows slight delays before sending individual small packets in order to combine them into a single larger packet.
Using Sockets Interface
#define TCP_NODELAY 1 SKT s; int off = 1; ... open socket, connect... setsockopt( s, IPPROTO_TCP, TCP_NODELAY, ( char * )&off, sizeof ( off ) );&
Using TLI Interface
#define TCP_NODELAY 0x01
#define INET_TCP 0x06
struct t_opthdr
{
unsigned long len;
unsigned long level;
unsigned long name;
unsigned long status;
/* kp_val isn't used for Nagle, but for keep alives. */
/* set to NULL for this sample. See IBSDS002 for keepalive sample*/
struct t_kpalive kp_val;
int tcp_nodelay;
};
/******************************************
Declare automatic variable for request & ret structures
******************************************/
struct t_optmgmt ret, request;
struct t_info info;
request.opt.buf = (char *) calloc( 1, sizeof( struct t_opthdr ) );
if( request.opt.buf == NULL )
{
printf("\nOut of memory error");
exit( 1 );
}
request.opt.len = sizeof( struct t_opthdr );
ret.opt.buf = (char *) calloc( 1, sizeof( struct t_opthdr ) );
if( ret.opt.buf == NULL )
{
printf("\nOut of memory error");
exit( 1 );
}
ret.opt.len = ret.opt.maxlen = sizeof( struct t_opthdr );
ret.flags = NULL;
request.flags = (long)T_NEGOTIATE;
( (struct t_opthdr * )request.opt.buf)->len =sizeof(struct t_opthdr);
( (struct t_opthdr * )request.opt.buf)->level=INET_TCP;
( (struct t_opthdr * )request.opt.buf)->name=TCP_NODELAY;
/* disable Nagles Algorithm */
( (struct t_opthdr * )request.opt.buf)->tcp_nodelay = 1;
if ((rc = t_optmgmt(fd, &request, &ret)) == -1 )&
{
t_error( "t_optmgmt" );
}
else
{
printf("\nt_optmgmt suceeded);
}
free( ret.opt.buf );
free( request.opt.buf );
File Information
Self-Extracting File Name: IBSDS003.EXE
|
Files Included: |
Size |
Date |
Time |
|
IBSDS003.TXT |
(this file) |
||
|
TCTLCLNT.C |
8682 |
3-10-98 |
9:34 AM |
|
IBSDS003.TXT |
4156 |
3-10-98 |
9:34 AM |
|
TCTLSERV.C |
10686 |
3-10-98 |
9:34 AM |
|
IBSDS003.MSG |
314 |
3-10-98 |
9:34 AM |
Delphi Application To Check DS Health
|
Author: |
RL |
|
Document ID: |
TID101543 |
|
Date: |
3/31/98 9:06 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
PARTCHK.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
This TID is about a sample Delphi 2.0x program that calls a variety of DS functions to verify the health and stability of a complex DS tree. This real life application illustrates the power of calling DS APIs from Delphi applications.
File Information
Self-Extracting File Name: PARTCHK.EXE
|
Files Included: |
Size |
Date |
Time |
|
PARTCHK.TXT |
(this file) |
||
|
SRVINFO.PAS |
9076 |
3-31-98 |
9:07 AM |
|
SRVINFO.DFM |
2072 |
3-31-98 |
9:07 AM |
|
SRVINFO.DCU |
10248 |
3-31-98 |
9:07 AM |
|
PARTCHK.RES |
876 |
3-31-98 |
9:07 AM |
|
PARTCHK.DSK |
3765 |
3-31-98 |
9:07 AM |
|
FCT.DOC |
879 |
3-31-98 |
9:07 AM |
|
PARTCHK.DOF |
21 |
3-31-98 |
9:07 AM |
|
MAIN.PAS |
66506 |
3-31-98 |
9:07 AM |
|
PARTCHK.DPR |
490 |
3-31-98 |
9:07 AM |
|
MAIN.DCU |
58198 |
3-31-98 |
9:07 AM |
|
HOW-TO.DOC |
5018 |
3-31-98 |
9:07 AM |
|
MAIN.DFM |
865 |
3-31-98 |
9:07 AM |
|
U_VARS.PAS |
1570 |
3-31-98 |
9:07 AM |
|
DELPHI_U.PAS |
33074 |
3-31-98 |
9:07 AM |
|
NW4.ICO |
766 |
3-31-98 |
9:07 AM |
|
NWSIPX32.DCU |
10493 |
3-31-98 |
9:07 AM |
|
PARTCHK.TXT |
2362 |
3-31-98 |
9:07 AM |
|
PARTCHK.MSG |
217 |
3-31-98 |
9:07 AM |
Information - CLIBAUX.NLM Is Officially Released by NTS
|
Author: |
AJ |
|
Document ID: |
TID101532 |
|
Date: |
3/6/98 5:21 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
ICLIBAUX.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
Novell Technical Services released CLIBAUX.NLM for NetWare 3.12, resolving NetWare loader errors such as:
Loader cannot find public symbol: NWstrnum
Detailed Description
(March 6, 1998) Novell Technical Services released a new library update for the NetWare 3.12 platform. It can be found at the following URL:
http://support.novell.com/cgi-bin/search/patlstfind.cgi?2935655
File contents are as follows:
Self-Extracting File Name: LIB312A.EXE
|
Files Included: |
Size |
Date |
Time |
|
A3112.NLM |
15906 |
02-11-97 |
5:55p |
|
AFTER311.NLM |
16127 |
02-11-97 |
5:54p |
|
CLIB.NLM |
344994 |
12-20-95 |
6:30p |
|
CLIBAUX.NLM |
7446 |
12-16-97 |
10:36p |
|
LIB312A.TXT |
2577 |
03-06-98 |
12:06a |
|
MATHLIB.NLM |
12458 |
12-20-95 |
5:27p |
|
MATHLIBC.NLM |
16832 |
12-20-95 |
5:27p |
|
NWSNUT.MSG |
2984 |
04-04-94 |
3:42p |
|
NWSNUT.NLM |
175546 |
10-17-94 |
9:14p |
The only change between LIB312.EXE and this new file (LIB312A.EXE) is the inclusion of CLIBAUX.NLM. This file adds certain public symbols (including structures and fruitions) that are necessary to run NLMs built with SDK CD Release 14 (and above) Novell has elected not to supply new CLIB.NLM versions for the NetWare 3.12 platform (beyond CLIB v3.12j). As the SDK was adapted to the NetWare 4.x platform, many new symbols (functions & structures) were introduced. The newly introduced symbols were, of course, not exported from CLIB 3.12j, but many were required by developers.
The first attempt to resolve this problem was to introduce a "FAT" prelude.obj. The "FAT" prelude supplied new symbols (at NLM link-time) that would not be available at load-time from CLIB v3.12jeven though these same symbols were available from 4.x versions of CLIB.NLM. Over time, "FAT" prelude continued to increase in size and it became apparent to Novell that another solution should be implemented.
SDK CD Rel. 14 (currently shipping) has returned to a "Skinny" prelude.obj. This version of prelude no longer exports the symbols needed on NetWare 3.12 platform. Rather, these symbols are now exported by a new library called CLIBAUX.NLM.
When loaded, the CLIBAUX.NLM verifies that CLIB.NLM has previously loaded. Then CLIBAUX.NLM determines which symbols are missing (but required for NLMs built with SDK CD 14). CLIBAUX.NLM then exports these specific symbols.
CLIBAUX.NLM ships with SDK CD Rel. 14, but has been in a "field test" state status. Today, Novell Technical Services moved it from a "field test" state to a "released" state.
Some of the symbols exported by CLIBAUX.NLM include:
assertassertCancelAbort
CountComponents
.FEQuickClose
FEQuickOpen
FEQuickRead
fstat_411
__get_daylight
__get_timezone
__get_tzname
IpxGetAndClearQ
IsMacintoshTextFile
is_unix_text_file
_LongJmp
NWLsetlocale_411
NWstrnum
NWLstrrev
opendir_411
pipe
readdir_411
ReturnOSLanguageID
ScanErasedFiles_411
etMacintoshTextMode
set_unix_text_mode
setjmp
setlocale_411
_SetupArgV_411
stat_411
UnsetMacintoshTextMode
unset_unix_text_mode
__I8D
__U8D
__U8RS
__I8RS
__I8LS
__U8LS
__FSU87
__FDU87
__U8FS7
__U8FD7
__old_8087
__ctype
gHugeValue
__fp_characteristics
If an NLM application is developed with SDK CD Release 14 (or above), and that NLM is loaded on NetWare 3.12, an error similar to the following may be displayed:
Loader cannot find public symbol: NWstrnum
To resolve this error, load CLIBAUX.NLM before loading the NLM application (built with SDK CD Rel. 14 or above).
File Information
Self-Extracting File Name: ICLIBAUX.EXE
|
Files Included |
Size |
Date |
Time |
|
ICLIBAUX.TXT |
(this file) |
||
|
ICLIBAUX.MSG |
158 |
3-6-98 |
5:21 PM |
Delphi Sample: Verify the Volume/Dir Attributes of NDS Queues
|
Author: |
WS |
|
Document ID: |
TID101531 |
|
Date: |
3/5/98 7:59 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
DQVER.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
DQVer is a Delphi 2.x/3.x application that illustrates the use of Delphi with NetWare APIs. It will allow you to scan for NDS Print Queues and fix errors that resulted from volume renames. General information on how to use Delphi with the NetWare SDK can be found in the HOW-TO.DOC file.
To run the application, you need to have installed the NetWare Client32.
Detailed Description
This tool allows you to check the NDS Print Queues of a selected container.
Problem The volume is stored in two locations of the NDS Print Queue object:
as Volume ID in the "Volume" attribute
as text in the "Queue Directory" attribute
When renaming a volume, this has no effect on the volume ID, but the "Queue Directory" attribute is not updated. Hence, the print queue becomes unusable and typically has to be recreated. This utility scans the specified containers for print queues and verifies the queue directories and volume names. It verifies if the volume name is correctly saved in the "Queue Directory" attribute and allows you to fix the "Queue Directory" property if necessary.
Admin rights on DS and file level are required.
DQVer demonstrates the following NetWare API functions:
NWCallsInitNWCCGetPrimConnRef
NWCCOpenConnByRef
NWDSAllocBuf
NWDSComputeAttrValSize
NWDSCreateContextHandle
NWDSGetAttrCount
NWDSGetAttrName
NWDSGetAttrVal
NWDSGetContext
NWDSGetSyntaxID
NWDSInitBuf
NWDSModifyObject
NWDSPutAttrName
NWDSPutAttrVal
NWDSPutChange
NWDSRead
NWDSSetContext
NWInitUnicodeTables
File Information
Self-Extracting File Name: DQVER.EXE
|
Files Included: |
Size |
Date |
Time |
|
DQVER.TXT |
(this file) |
||
|
QVERIFY.EXE |
296960 |
3-5-98 |
7:59 AM |
|
DELPHI_U.PAS |
39276 |
3-5-98 |
7:59 AM |
|
DELPHI_U.DCU |
25227 |
3-5-98 |
7:59 AM |
|
MAIN1.PAS |
17283 |
3-5-98 |
7:59 AM |
|
MAIN1.DCU |
16123 |
3-5-98 |
7:59 AM |
|
HOW-TO.DOC |
5958 |
3-5-98 |
7:59 AM |
|
MAIN1.DFM |
3395 |
3-5-98 |
7:59 AM |
|
QVERIFY.DSK |
3270 |
3-5-98 |
7:59 AM |
|
U_ABOUT.DCU |
2406 |
3-5-98 |
7:59 AM |
|
U_ABOUT.DFM |
1899 |
3-5-98 |
7:59 AM |
|
QVERIFY.DOF |
932 |
3-5-98 |
7:59 AM |
|
QVERIFY.DPR |
352 |
3-5-98 |
7:59 AM |
|
QVERIFY.RES |
876 |
3-5-98 |
7:59 AM |
|
NWADMIN.ICO |
766 |
3-5-98 |
7:59 AM |
|
U_ABOUT.PAS |
610 |
3-5-98 |
7:59 AM |
|
READ.ME |
889 |
3-5-98 |
7:59 AM |
|
DQVER.MSG |
366 |
3-5-98 |
7:59 AM |
Name Completion Control Sample Update for Delphi 3
|
Author: |
RL |
|
Document ID: |
TID101537 |
|
Date: |
3/16/98 1:27 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
GW5XNC01.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
This is a sample Name Completion application that will work with Delphi 3. Delphi 3 imports the controls with different names by default than Delphi 2.
File Information
Self-Extracting File Name: GW5XNC01.EXE
|
Files Included: |
Size |
Date |
Time |
|
GW5XNC01.TXT |
(this file) |
||
|
NCCSAMP.EXE |
289280 |
3-16-98 |
1:27 PM |
|
NCCSAMP.DPR |
195 |
3-16-98 |
1:27 PM |
|
NCC.DFM |
759 |
3-16-98 |
1:27 PM |
|
NCC.PAS |
1740 |
3-16-98 |
1:27 PM |
|
GW5XNC01.MSG |
153 |
3-16-98 |
1:27 PM |
Delphi Sample: Read and Verify Private GW Address Books/Groups
|
Author: |
WS |
|
Document ID: |
TID101529 |
|
Date: |
3/5/98 7:13 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
GWADDVER.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
GWAddVer is a Delphi 2.x/3.x application that illustrates the use of Delphi with GroupWise Object APIs. It will display the current GW address books and allow you to verify your private address books or private groups against the system address book. Doing so reduces the risk of receiving D101 errors. These might occur when a user GW ID is changed or deleted in the system address book, but not modified in your private books/groups. GroupWise's quick address resolution might retrieve the GW ID from your private books, thus sending to the obsoleted address.
Platform Windows, Windows 95, or Windows NT
Compilers Borland Delphi 2.x/3.x
File Information
Self-Extracting File Name: GWADDVER.EXE
|
Files Included: |
Size |
Date |
Time |
|
GWADDVER.TXT |
(this file) |
||
|
GWADDRBU.PAS |
16594 |
3-5-98 |
7:13 AM |
|
HOW-TO.DOC |
5958 |
3-5-98 |
7:13 AM |
|
GWADDRBU.DFM |
3845 |
3-5-98 |
7:13 AM |
|
GWADDVER.DSK |
2741 |
3-5-98 |
7:13 AM |
|
GWADDVER.DOF |
1042 |
3-5-98 |
7:13 AM |
|
GWADDVER.RES |
876 |
3-5-98 |
7:13 AM |
|
GWADDVER.DPR |
243 |
3-5-98 |
7:13 AM |
|
READ.ME |
668 |
3-5-98 |
7:13 AM |
|
NWADMIN.ICO |
766 |
3-5-98 |
7:13 AM |
|
GWADDVER.EXE |
205312 |
3-5-98 |
7:13 AM |
|
GWADDVER.MSG |
647 |
3-5-98 |
7:13 AM |
Error: NWSNUT-4-10-47: This NLM Contains No Messages
|
Author: |
WS |
|
Document ID: |
TID101530 |
|
Date: |
3/5/98 7:16 AM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
MSGTOOLS.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
Q. My NLM that uses NWSNUT runs fine on NetWare v4.1x, but on NetWare 3.1x it fails with the message: "NWSNUT-4-10-47: This NLM contains no messages".
A. When loading your files on NW v3.1x, either load the NLM from SYS:SYSTEM, or add the location of the NLM to the NLM search path using the console command SEARCH.
File Information
Self-Extracting File Name: MSGTOOLS.EXE
|
Files Included: |
Size |
Date |
Time |
|
MSGTOOLS.TXT |
(this file) |
||
|
MSGTOOLS.TXT |
1787 |
3-5-98 |
7:16 AM |
|
MSGTOOLS.MSG |
321 |
3-5-98 |
7:16 AM |
SPX Send Example for Windows 3.x
|
Author: |
EE |
|
Document ID: |
TID101536 |
|
Date: |
3/11/98 7:15 PM |
|
Alert status: |
Yellow |
|
Information type: |
Issue |
|
Readme for: |
XSPXE001.EXE |
|
Novell product class: |
NetWare API |
|
Novell product andversion: |
NetWare SDK |
|
Category: |
None |
Abstract
This sample code demonstrates the proper steps to establish an SPX connection using SPXEstablishConnection() and then send packets to a partner node using SPXSendSequencedPacket(). The SPX connection is then torn down using SPXTerminateConnection(). The partner sample program to this one is SPXREC.EXE.
File Information
Self-Extracting File Name: XSPXE001.EXE
|
Files Included: |
Size |
Date |
Time |
|
XSPXE001.TXT |
(this file) |
||
|
XSPXE001.MSG |
307 |
3-10-98 |
2:52 PM |
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.