JANUARY 1993 VOLUME 5 NUMBER 1
INDEX
Hello and welcome to the January 1993 issue of Bullets!
In past issues, I have touched on planned enhancements for developer support and developer
programs. An exciting new enhancement you will soon be seeing in documents like the Novell
Developers Guide is the SDK Grading System.
What is this SDK Grading System, you ask? Quite often, I find a disparity between the implied
maturity of an SDK and the needs of the developer community. The SDK Grading System is
structured to eliminate the guesswork that is sometimes associated with SDKs.
Some developers don't want to see an SDK unless it has been completely unit- and system-tested,
with documentation either nicely bound or stored on a CD, and for which education classes and
telephone support are available. Other developers are interested in an SDK at a very early stage,
when the APIs are still forming, documentation is a less formal collection of header files and
developer notes, and support is not yet provided.
To produce the SDK Grading System, input (in the form of grades) is gathered from the various
groups (Engineering, Documentation, Marketing, Education, Testing, Support, etc.). This input is
then combined to determine an overall grade for each SDK. An SDK's "grade" may change over
time. We hope that this process will help Novell's developers establish their expectations for
SDKs.
Happy_Programming!
Mad Poarch
Director
Developer Support/Service
Getting Started with NetWare 4.0: Directory Services
With NetWare 4.0, Novell has introduced Directory Services to replace the traditional
NetWare bindery employed by previous versions. NetWare 4.0 Directory Services provide many
new features and capabilities. Directory Services functionality is provided through an extensive
new Application Program Interface (API).
This article presents a basic introduction to NetWare 4.0 Directory Services and is not intended
to replace a thorough study of the documentation. It discusses several of the new features and
advantages of Directory Services and offers a few tips and some general information to help you
begin writing Directory Services applications more quickly. Converting existing applications
from the bindery to Directory Services is also discussed. This article also includes example code
that creates a Directory Services User class object to provide a starting point for using the
Directory Services API.
Advantages of Directory Services
NetWare 4.0 Directory Services provides a hierarchical database architecture to store
network information. This architecture, combined with advanced techniques for retrieving and
storing database information, provides a very flexible environment for application development.
One of the most beneficial Directory Services features is the network global scope of objects in
the directory. An application with sufficient NetWare rights may retrieve information about any
object in the directory without needing to be attached to any specific server. Access to a
Directory Services object and its attribute information is limited solely by the access rights of the
client, without regard to server connection status.
Another very useful feature that is built into the Directory Services API is that changes made to
the directory database are atomic. When an application makes changes to the directory database,
each change is completely defined before the change to this database is attempted. When the
change is actually made to the database, if any part of the operation fails, the entire operation
fails. This makes it virtually impossible for partially defined objects to exist in the directory.
With NetWare 4.0 Directory Services, no space is wasted in a directory database because no
minimum size is defined for information describing objects and attributes. Objects are stored
only once in the directory, reducing the overall size of the database.
The hierarchical database structure of Directory Services design reduces network traffic and
makes retrieving objects and attributes very easy and efficient. You need not search the entire
database tree to locate an object; searching may be performed at any level of the tree. Enhanced
searching techniques allow objects to be located in a variety of ways, such as using relational
expressions and wild cards. Also, objects in the directory do not advertise. Network traffic is
generated only when an application asks the directory for information.
Finally, the entire NetWare 4.0 Directory Services Schema (the rules that define how the
directory tree is constructed) may be modified and expanded by applications to suit specific
needs. If the defined schema does not meet your needs, you may define an entirely new schema,
or make modifications to parts of it. This feature adds greater flexibility to the NetWare 4.0
environment.
Developing Directory Services Applications
Developing Directory Services applications requires an understanding of concepts and
ideas very different from the knowledge required to use the bindery. When you begin studying
the manuals related to Directory Service applications, there are several things that you should
keep in mind:
- You do not need to understand everything about Directory Services to use the
Directory Services API and begin writing applications.
- Though writing directory applications may initially seem to be more complex than
writing bindery applications, the directory is often easier to use.
- Novell will continue to support all bindery APIs for some time, so you may continue to
use bindery calls to perform operations until you are familiar with their directory equivalents. If
you are already very familiar with the bindery, it may in some cases be easier to write a bindery
application and then convert it to Directory Services.
Context & Buffer Management
Begin learning how to write applications for the directory by investigating the APIs for
context and buffer management. Almost all Directory Services functions require a context handle
and a buffer. The context handle provides information about the location in the directory of the
object to be manipulated, while the buffer defines the operation that you want to perform.
Creating a context handle may only be required once for the life of an application, but the
creation and definition of buffers will probably be required for each individual operation
performed in the directory. There are several APIs that you can use to manipulate contexts.
NWDSCreateContext() and NWDSFreeContext() are the only two that you will need to begin
writing applications. There are many APIs that create, manipulate, and free buffers. The
functions NWDSAllocBuf(), NWDSInitBuf(), and NWDSFreeBuf() create and initialize buffers
and are almost always required when performing directory operations. The NWDSPut...() and
NWDSGet...() series of functions are used to store and retrieve information in the allocated
buffers. You will use some arrangement of these calls to define the buffers which you will then
use as parameters to other functions to perform directory operations. None of the buffering
functions will change any information stored in the directory. These functions are used only to
define the information required to perform operations. The directory database is not modified
until a directory call is made.
Once you are familiar with contexts and buffers, start making directory calls. Stay away from the
more complex operations at first (such as defining new attributes or classes, manipulating access
control lists, and creating partitions). Begin with some of the more straightforward operations,
such as creating new objects and reading attribute information from existing objects.
The functions NWDSAddObject(), NWDSRead(), NWDSSearch(), NWDSModifyObject(), and
NWDSRemoveObject(), are sufficient to perform many useful directory operations while
introducing you to the capabilities of the directory database.
NWDSRead() and NWDSSearch() perform similar operations: NWDSRead() is used to get
information about an object when you know the object's name, while NWDSSearch() is used to
scan the entire directory for object names and return information about them. Remember that all
of these functions except NWDSRemoveObject() require that the buffer initialization and
manipulation functions be used to define the buffers necessary to make the directory call.
NWDSRemoveObject() requires only the name of the object to be removed.
Constant values (defined in the header file NWDSDEFS.H) are used in buffer management
functions to specify which operation is desired. For example, the constant DSV_ADD_ENTRY
is passed to NWDSInitBuf() to define a buffer to be used when adding a new object to the
directory. NWDSAddObject() is called with the defined buffer to add the object.
DSV_MODIFY_ENTRY would be passed to NWDSInitBuf() to define a buffer to be used to
change an object's definition in the database. The actual change is performed by calling
NWDSModifyObject() with the defined buffer.
If attribute values (similar to property values in the bindery) are to be defined,
NWDSPutAttrName() and NWDSPutAttrVal() are required to place the attribute names and
values in the buffers. Attribute values may be defined when an object is created, or they may be
added to existing objects by using NWDSModifyObject().
To perform these types of operations, review the Directory Services Schema documentation to
learn what attribute information is available with the various object classes. The User object class
is a good place to begin, since it is a very common class and is used frequently by the NetWare
4.0 directory. In the directory, the User object class is analogous to the OT_USER bindery object
type in the bindery, so this class is probably a familiar place to start.
Client & Server Considerations
There is very little distinction between the server and client environments when writing
applications that use directory services. The only difference is that, when writing client
applications, you must initialize the Unicode tables by calling the NWDSInitUnicodeTables()
function before calling any Directory Services functions. The required Unicode files are provided
with NetWare. Consult the documentation to determine where these files must be located to
ensure that applications can find them during the initialization process.
The Directory Services header files use the constant value NLM to differentiate between server
and client applications. You may also use this constant to compile conditionally for the two
environments, making it unnecessary to have two versions of the source code.
Compilation in the two environments requires the use of several new header files that
support the Directory Services APIs. For linking, there is a new import file for NLMs and there
are new libraries for client applications. NLMs should include the DSAPI.IMP import file when
linking, and client applications should include the NWNET.LIB, NWCALLS.LIB, and
NWLOCALE.LIB libraries.
Converting Bindery-Based Apps to Directory Services
After becoming familiar with some of the basic Directory Services APIs, converting a
bindery application to use Directory Services is fairly easy. Although there is no "one-to-one"
correspondence between bindery and directory functions, the subset of directory functions that
replace the functionality of the bindery is relatively small. When you learn to use the functions
required to control and access objects and attributes in the directory, you understand the majority
of the functions needed to convert a bindery-based application to run in the Directory Services
environment.
Since the bindery functions will still be supported for some time, you do not need to convert
your entire application to Directory Services at once. It is possible (and in some cases desirable)
for applications to use a combination of directory and bindery functions. During the gradual
transition from bindery networks to directory networks, your applications may even need to
operate in both environments.
The most important part of the process of converting to the directory is determining which
directory functions provide the greatest benefit to your application and implementing those
functions first. You must then decide which bindery functions your application should continue
to use in order to maintain backward compatibility with previous versions of NetWare. The two
sets of functionality can exist in harmony, but you should upgrade all of your bindery functions
to the directory as time permits, leaving only those bindery functions that your application
requires to support previous versions of NetWare. Figure 1 below contains several examples of
common bindery functions and directory functions that perform similar operations.
FIGURE 1: Common bindery functions and associated directory functions
Bindery Function Directory Services Function
=============================================================
CreateBinderyObject() NWDSAddObject()
-------------------------------------------------------------
DeleteBinderyObject() NWDSRemoveObject()
-------------------------------------------------------------
ReadPropertyValue() NWDSRead, NWDSSearch()
-------------------------------------------------------------
ScanBinderyObject() NWDSRead, NWDSSearch()
-------------------------------------------------------------
ScanProperty() NWDSRead, NWDSSearch()
-------------------------------------------------------------
WritePropertyValue() NWDSModifyObject()
-------------------------------------------------------------
END of FIGURE 1
Several bindery functions are replaced by NWDSRead() and NWDSSearch(). This is
made possible by the buffer management concept used by directory functions. The definition of
the buffer controls how an operation will be performed in the directory. Then, after a buffer is
correctly defined, making the directory function call to perform the operation is very
straightforward. If an operation fails, it is most likely due to an incorrect buffer definition. This
can usually be caught before the directory call is made by checking the return codes from the
buffering functions, but this is not always the case.
The buffering functions themselves do not affect the directory database. The buffering functions
check for proper syntax when creating the buffers, but they have no knowledge of what
information exists in the directory. For example, if you define a buffer that includes attribute
information, the buffering functions will check to ensure that the attribute names and values are
specified in the proper format. However, if you misspell an attribute name, no error will occur
until the directory call is actually made. If you get an error code from a directory function,
correcting it will probably require changing one of the buffering function calls, not the directory
call.
Example Code
The example code in Figure 2 below illustrates one of the most common directory service
operations: creating a new directory object of the User class.
FIGURE 2: Creating a new "User" directory object
#define LOGIN_NAME "Admin"
#define PASSWORD ""
#define OBJECT_NAME "Example User Object"
#define SURNAME "Example Surname"
#define ESUCCESS 0
#include
#include
#include
NWDSContextHandle Context;
int ExampleCreateDSObject( char *objectName, char *surName )
{
int ccode;
int32 interationHandle;
Buf_T *attributes;
ccode = NWDSAllocBuf(DEFAULT_MESSAGE_LEN, &attributes);
if(ccode < ESUCCESS)
return ccode;
ccode = NWDSInitBuf(Context, DSV_ADD_ENTRY, attributes);
if(ccode < ESUCCESS)
goto freeBuffers;
ccode = NWDSPutAttrName(Context, attributes, A_OBJECT_CLASS);
if(ccode < ESUCCESS)
goto freeBuffers;
ccode = NWDSPutAttrVal(Context, attributes,
SYN_CLASS_NAME, A_USER);
if(ccode < ESUCCESS)
goto freeBuffers;
ccode = NWDSPutAttrName(Context, attributes, A_SURNAME);
if(ccode < ESUCCESS)
goto freeBuffers;
ccode = NWDSPutAttrVal(Context, attributes,
SYN_CI_STRING, surName);
if(ccode < ESUCCESS)
goto freeBuffers;
interationHandle = NO_MORE_ITERATIONS;
ccode = NWDSAddObject(Context, objectName, &interationHandle,
FALSE, attributes);
freeBuffers:
NWDSFreeBuf(attributes);
return ccode;
}
void main( void )
{
int ccode;
#ifndef NLM
ccode = NWInitUnicodeTables(001, 437);
if(ccode < ESUCCESS)
{
printf("NWDSInitUnicodeTables returned %d\n", ccode);
exit(1);
}
#endif
Context = NWDSCreateContext();
if((long)Context < ESUCCESS)
{
printf("NWDSCreateContext returned %d\n", (int)Context);
exit(1);
}
ccode = NWDSLogin(Context, 0, LOGIN_NAME, PASSWORD, 0);
if(ccode)
{
NWDSFreeContext(Context);
printf("NWDSLogin returned %d\n", ccode);
exit(1);
}
ccode = ExampleCreateDSObject(OBJECT_NAME, SURNAME);
printf("AddNWDSObject returned %d\n", ccode);
NWDSLogout(Context);
NWDSFreeContext(Context);
}
END of FIGURE 2
The mainline performs several operations that are required in most directory
applications:
- Initializing the Unicode tables,
- Creating a context,
- Logging in, and
- Freeing all of these resources after the directory operations are complete.
Notice that the "#ifndef" operator is used for conditional compilation of the
NWDSInitUnicodeTables() function call. The example code creates a global context handle that
is used throughout the rest of the program. A login is necessary (using NWDSLogin()) to obtain
the required access rights for creating objects. Some functions (e.g., functions that read and
search directory information) do not require the application to be logged in to the directory, since
some objects allow access to read their attributes with no restrictions. For example, no login is
required to read the Network Address attribute of a server when the name of the server object is
known.
ExampleCreateDSObject() provides examples of buffer creation and initialization. Buffer
manipulation functions put into the buffer the information required to define the object to be
created. The buffer is initialized with the DSV_ADD_ENTRY constant, since a new object is
being added. The only attribute information that must be placed in the buffer is for the mandatory
attributes Object Class and Surname. The Common Name is also a mandatory attribute, but this
name is supplied as one of the parameters (objectName) to NWDSAddObject().
The NWDSAddObject() call uses the information defined in the buffer to add the object to the
directory database. Remember that if any part of the add operation fails (for example, if one of
the attribute names is undefined), the entire operation will fail and the object will not be created.
As you make changes to the directory database, you will begin to notice a pattern of function
calls that is repeated for most operations. The table in Figure 3 lists the basic steps required to
accomplish most directory database operations and each operation's corresponding functions.
FIGURE 3: Steps required for directory database operations & each operation's
corresponding function calls
Operation Directory Function Call
=============================================================
Initialize the Unicode tables NWDSInitUnicodeTables()
(client applications only)
-------------------------------------------------------------
Create context NWDSCreateContext()
-------------------------------------------------------------
Login NWDSLogin()
-------------------------------------------------------------
Allocate buffers NWDSAllocBuf()
-------------------------------------------------------------
Initialize buffers NWDSInitBuf()
-------------------------------------------------------------
Define buffers NWDSPut...()
-------------------------------------------------------------
Perform the Directory Operation NWDSAddObject()
NWDSModifyObject()
...
-------------------------------------------------------------
Retrieve buffer information NWDSGet...()
-------------------------------------------------------------
Free buffers NWDSFreeBuf()
-------------------------------------------------------------
Logout NWDSLogout()
-------------------------------------------------------------
Free context NWDSFreeContext()
-------------------------------------------------------------
END of FIGURE 3
These steps are not absolute; depending on the operation, more, fewer, or different steps
may be required. This is just a general outline you can use as a starting point.
NetWare 4.0 Directory Services offers new features and advantages that make developing in a
network environment easier and more flexible. Writing applications that take advantage of the
directory requires careful planning, but the advantages are well worth the effort. Converting
existing bindery-based applications to Directory Services gives applications greater flexibility,
especially while hybrid bindery-and-directory networks exist that allow applications to be
converted to the directory in stages. Once you are familiar with the directory, you will find that
the capabilities provided by NetWare 4.0 Directory Services make NetWare applications
development an even more rewarding and profitable endeavor.
You can gain access to the Directory Services API through the NLM SDK for NetWare 4.0 and
the NetWare Client SDK. You must be a member of a Novell Developers' Program to purchase
these SDKs. For more information on these SDKs and the Novell Professional Developers'
Program, call 1-800-NETWARE or 1-801-429-5588 (in the U.S. and Canada), or contact your
local international Novell office.
Creating Btrieve Quick Libraries for Visual Basic for DOS (Btrieve (all versions))
When developing Btrieve applications using the Microsoft Visual Basic for DOS
interpreter environment (VBDOS), you must create a Quick Library that includes the required
Btrieve interface. To create this Quick Library, use the following link command:
Link /q BC7RBTRV.OBJ, BC7.QLB,, VBDOSQLB.LIB;
where BC7RBTRV.OBJ is the Btrieve interface, BC7.QLB is the name of the Quick Library,
and VBDOSQLB.LIB is the name of the required library. To load the Visual Basic for DOS
environment to include the newly created Quick Library execute the following command:
VBDOS /L BC7
Header File Inconsistencies (NetWare C Interface for DOS v1.2)
In DIAG.H, the fields, linkAddress and ESRAddress, in the ECB structure are defined as
an array of WORD. In NXT.H, linkAddress and ESRAddress are defined as far pointers. These
inconsistent ECB structure definitions can cause some problems if an ESR is defined in your
application and the include file DIAG.H exists before NXT.H.
To resolve this inconsistency, either avoid including DIAG.H before NXT.H in applications that
make IPX calls, or modify the linkAddress and ESRAddress fields in DIAG.H as follows:
void far *linkAddress;
void (far *) ();
The above definition should be included for applications that do not use ESR routines.
Borland's Default open() Mode (NetWare C Interface for DOS v1.2)
After writing to a file through the Queue Services API, extra 0x0D (Carriage Return)
characters may be left in the file. These extra characters remain because the Queue Services API
assumes that the file will be open in Binary mode. For example, in the SERVJOB.C module,
open() is called without specifying the mode in which the file should be open. If Borland's C++
v3.1 compiler is used to open the file, it defaults to text filtering which causes some extra
characters to appear in the file.
To prevent the introduction of these extra 0x0D characters, change Borland's default open()
mode by including the following lines in your code:
extern int _fmode;
_fmode = O_BINARY;
New Status Codes for NetWare SQL v3.0 (NetWare SQL v3.0)
Several status codes have been added to NetWare SQL since the release of version 3.0.
These status codes are not documented in NetWare SQL Status Codes and Messages (Jan. 1992
ed.).
350 Security is not enabled on dictionary
You have attempted to perform an operation that can only be done when security is enabled.
Database security is not enabled at this time.
351 Transaction is not started yet
You must start a transaction before performing a COMMIT or ROLLBACK operation.
886 Incorrect Btrieve file version for this operation
Referential integrity constraints can only be defined on Btrieve file versions 6.0 or later. If you
wish to add referential integrity to this file, use BREBUILD to convert it to the v6.0 file format.
887 CREATE TABLE statement cannot reference the same table more than once
This status code is returned in place of 568; status code 568 is not actually used. For more
details, check the NetWare SQL Status Codes and Messages manual under "status code 568."
888 A primary key is already defined on this table
A table may contain only one primary key and you have attempted to define a second primary
key on this table.
Must Scan Salvagable Files Before Purging (NetWare C Interface for DOS v1.2)
The NetWare C Interface for DOS v1.2 documentation incorrectly states that an initial
search can be performed by setting entryID to "-1." Setting the entryID parameter in
PurgeSalvagableFile() to "-1" as suggested in the documentation always causes it to fail.
PurgeSalvagableFile() cannot scan for files to be purged.
You must call ScanSalvagableFiles() to get a valid entryID value before calling
PurgeSalvagableFile(). This entryID will allow PurgeSalvagableFile() to identify the directory
entry to be purged.
readdir API Returns Invalid Date/Time (Network C for NLMs v2.0(d))
The readdir API is returning date/time fields in a format that is similar to the DOS
date/time format, but not identical. Differences between the formats cause SetFileInfo() to set the
time and date information incorrectly if the fields are passed directly from readdir().
The documentation states that dates should be stored in DOS format for SetFileInfo(). However,
to accomplish this, the dates/times returned from readdir() must be modified. The four-byte
date/time value must have the two WORDs, "AA BB" and "CC DD," swapped, but the WORDs
themselves should not be swapped. For example,
AA BB CC DD
needs to be stored as
CC DD AA BB
Simply using LongSwap does not resolve this situation, since LongSwap also swaps the values
within the WORDS as well. To ensure that date/ time values are set properly, swap only the
location of the two WORD values. Figure 4 contains an example that assumes the receiving
fields have been defined as character arrays.
FIGURE 4: Example of Date/Time format change
*(WORD *)lastUpdateDateAndTime = dirP->d_date;
*(WORD *)&lastUpdateDateAndTime[2] = dirP->d_time;
*(WORD *)creationDateAndTime = ((WORD *)(&dirP->d_cdatetime))[1];
*(WORD *)&creationDateAndTime[2] = ((WORD *)(&dirP->d_cdatetime))[0];
*(WORD *)lastAccessDate = ((WORD *)(&dirP->d_adatetime))[1];
*(WORD *)lastArchiveDateAndTime = ((WORD *)(&dirP->d_bdatetime))[1];
*(WORD *)&lastArchiveDateAndTime[2] = ((WORD *)(&dirP->d_bdatetime))[0];
END of FIGURE 4
Printing Through Xtrieve PLUS - Tabloid Setting Correction (Xtrieve PLUS v4.11)
In the XTRIEVE.PDB file that ships with NetWare SQL v3.0, the TABLOID setting is set
to EPSON LQ-1500/2.0, rather than IBM PC Graphics printer. To change the TABLOID setting
to IBM PC Graphics printer, the printer information needs to be altered as follows:
- At the DOS prompt type
"SLATE XTRIEVE.PDB"
- Select "Add/Edit Devices (Ptr Connections)"
- Select "3001 Tabloid"
- Tab to "Ptr Mfg"
- Press F9 [Lists]
- Select "IBM"
- Tab to "Ptr Type"
- Press F9 [Lists]
- Select "PC Graphics Printer"
- Press F10 [Prev Screen]
Press F10 [Prev Screen]
Press F10 [Exit]
MapDrive() and Windows (NetWare C Interface for Windows v1.3)
The Windows MapDrive() function can only modify an existing search drive, it cannot add
a new one. In order to add a search drive under Windows, a dummy search drive is required
before bringing up Windows. Then, this search mapping can be modified using MapDrive().
Get Next Extended Operation after Get Key (NetWare Btrieve v5.15, Btrieve for DOS
v5.10a)
If you use the GetKey bias (+50) when establishing positioning before a Get Next
Extended (38) operation, the extended operation will not function properly, returning either a
status 19 (Unrecoverable Error) or erroneous information in the databuffer. This situation occurs
with Btrieve for DOS v5.10a and NetWare Btrieve v5.15.
Patch #57, available on Novell's NetWire forum on CompuServe (NOVLIB, LIB 7), resolves the
situation for NetWare Btrieve v5.15. There is currently no patch for Btrieve for DOS v5.10a, so
avoid using the GetKey bias before Get Next Extended operations. Instead, use a Get First (12),
Get Equal (5), or some other operation to establish positioning without the +50 bias.
NetWare Btrieve & New Intel NE3200 Driver (NetWare Btrieve (NLM) v5.15)
File corruption can occur when you use Intel's NE3200.COM driver (09-03-91, 19242
bytes) in conjunction with Intel's EtherExpress 32bit card on workstations running Btrieve
applications. Intel describes the situation as:
"... a problem with the Ether-Express 32 and applications that use extended memory or memory
managers (i.e. MicroSoft Windows 3.x). Previous versions of this driver would not protect
memory regions from the above mentioned applications. This could cause files that the
EtherExpress 32 stored in memory to be overwritten (corrupted) if an application wrote to that
address space."
Intel has a new NE3200.COM driver (date: 05-04-92, size: 25967) which fixes these problems
through the use of the keyword "DOUBLE BUFFER" in the NET.CFG file. This driver is still in
Beta and has not completed certification. This driver defaults to an 802.2 frame type; if you need
a different frame type, include a "FRAME" statement in the NET.CFG file. Figure 5 contains a
sample NET.CFG file. Note that this file requires the NE3200.COM driver to be in the same
directory as itself.
FIGURE 5: Sample NET.CFG file for NE3200.COM driver
LINK DRIVER NE3200
SLOT 5
DOUBLE BUFFER
FRAME ETHERNET_802.3
PROTOCOL IPX 0 ETHERNET_802.3
PROTOCOL IPX
BIND NE3200
END of FIGURE 5
Substitution Variables & NetWare SQL Inserts (NetWare SQL v3.0a)
When inserting records through a substitution variable, if the data being inserted contains
the "@" character, all subsequent inserts with the same cursor are given the same data for that
field. NetWare SQL is confusing the "@" in the data with a substitution variable indicator.
FIGURE 6: NetWare SQL inserts resulting in incorrect field data
XQLCompile of "INSERT INTO Patients (ID, First^Name, Last^Name, Address)
VALUES (@V1, @V2, @V3, @V4)"
XQLSubst where
V1 = "A11111" V2 = "John" V3 = "Smith" V4 = "100 Main @ 1st"
XQLExec (performs Insert successfully)
XQLSubst where
V1 = "B22222" V2 = "Mary" V3 = "Brown" V4 = "222 Central Ave."
XQLExec (performs Insert successfully)
END of FIGURE 6
For example, in Figure 6, the second insert (and all subsequent inserts based on the same
XQLCompile command) will result in each record being inserted with the same address as the
first record: "100 Main @ 1st".
This occurs with any application making the above calls, and when using the Load option of the
NetWare SQL Maintenance Utility (NSUTIL.EXE and NSUTIL.NLM), since it uses these calls.
With NSUTIL, the problem will occur in each file format: SDF, UNF, DIF or ASC.
To resolve the situation and ensure that each record is inserted with the correct address, upgrade
to the latest release of NetWare SQL, version 3.0b (avail. Dec. 92). To obtain v3.0b, download
SQL30.ZIP form the NOVLIB forum on CompuServe, or contact Novell Developer Support (see
"Contacting Novell," page 11). Otherwise, the only work-around is to recompile the statement
between XQLSubst/XQLExec calls, or append the actual data values into the Insert statement
passed in on the XQLCompile command, instead of using the substitution variables.
Unique Passwords (NetWare v3.11)
If the "Unique Passwords" requirement is enabled through SYSCON, and a password is
changed to one of the old passwords through SYSCON, the password is accepted and no error
messages are returned.
Whenever you change a password through SYSCON, the password expiration date defaults to
January 1, 1985. Unless you change this expiration date to a date later than the current date,
SYSCON will accept any passwords that were used previously even though the "Unique
Passwords" restriction is on. Therefore, make sure that the password expiration date is valid.
Determining If Data Dictionary Files are Corrupted (Xtrieve PLUS v4.1x)
When you attempt to add fields to a view and when recalling views, if the .DDF files are
damaged, Xtrieve PLUS v4.1x returns status 207 (Field Does Not Exist in Dictionary) or status
240 (Field in the View Definition Is Not in the Active Dictionary).
In the Xtrieve PLUS User's Manual (for DOS and OS2), Appendix D lists Dictionary Structures
for all of the .DDF files. With Xtrieve PLUS for NetWare SQL, the Dictionary Structures are
shown in Appendix C. Each description lists the field and index names for each .DDF file.
Specifics are given for field data types and sizes, and key flags, such as duplicates, case
sensitivity, and segments.
To view the .DDF file definitions in Xtrieve PLUS, the CONFIGURE/
SWITCHES/DICTIONARY option must be set to "Yes." Then, the .DDF file definitions can be
viewed through the DICTIONARY/SHOW option. To resolve this situation, use VIEW/FILE to
compare the field and index information described by the user's manual for the .DDF files with
the set of .DDF files you are using. A comparison should be made of the field and index
information. If any of the information does not match exactly, then the .DDF files are probably
corrupted.
One more thing to note is that if a Btrieve BUTIL -STAT is executed on the DDF files, the
results may not match the dictionary file definitions viewed in Xtrieve if the files are corrupted.
.DDF files created with NetWare SQL will have a supplemental index defined for X$Field
(FIELD.DDF), but this is only shown in the NetWare SQL Developer's Kit Getting Started
manual which shipped with NetWare SQL 3.0. This fourth supplemental index is not shown in
the Xtrieve PLUS User's Manuals, and is only defined if the dictionaries were created with
NetWare SQL.
To recover corrupted data dictionary files, use MAKE_XTA to extract each file definition. Then,
use XCFP to create a command file to rebuild each file. This process can be partially automated
by performing the following steps:
- Using XQLI or any other SQL statement processor, execute the following
statement to extract the file names from the dictionary files and save the output to an ASCII file:
SELECT Xe$Name FROM X$File
(to extract file definition names)
Then, edit the ASCII file so that it does not contain any of the dictionary file names (X$File,
X$Field, etc.)
- Edit the ASCII file so that each file definition is recoverable using MAKE_XTA and
XCFP as follows: The result from the SELECT statement above was:
FILEDEF1
FILEDEF2
FILEDEF3
Next, edit the ASCII file to look like this (you may have to cut and paste quite a bit, but it's
worth it if you have many files):
MAKE_XTA /F:"FILEDEF1"
XCFP MAKE_XTA.XTA FILECMD1
MAKE_XTA /F:"FILEDEF2"
XCFP MAKE_XTA.XTA FILECMD2
MAKE_XTA /F:"FILEDEF3"
XCFP MAKE_XTA.XTA FILECMD3
Then, rename the resulting ASCII file with a .BAT extension.
- Create a new set of .DDF files in another directory using the Xtrieve PLUS
DICTIONARY/CREATE option.
- Run the batch file in the directory with the corrupted .DDF files. It will create command
files, with a .XTC extension, which can be played back against the new .DDF files created in
Step 3.
- To recover view definitions, repeat Step 1 with the following statement:
SELECT Xv$Name FROM X$View
Then, repeat Step 2 using the result from the SELECT statement, editing the ASCII file as
follows:
MAKE_XTA /V:"viewname"
XCFP MAKE_XTA.XTA VIEWCMD1
.
.
.
Finally, repeat Step 4.
Prototype Missing from CLib (Network C for NLMs SDK v2.0(e))
In the Network C for NLMs SDK, the ioctl() prototype is missing from the header files of
CLIB.NLM v.3.11 b. This generates a warning message from the compiler. For now, you can
safely ignore this warning message. The prototype will be included in a later release.
Create/Drop Index Operations within a Transaction (NetWare SQL v3.0)
With NetWare SQL, if an application performs a Create Index or Drop Index operation on
a table within a transaction after it has previously updated the same table within the same
transaction, the updates will be committed when the Create Index or Drop Index operation
completes. The updates cannot be rolled-back, even though the application has not yet issued the
COMMIT/ROLLBACK statement.
This anomaly occurs because NetWare SQL must temporarily disable transactions to Btrieve in
order to perform the Btrieve Create Index or Drop Index operation. When this operation is
complete, all outstanding updates to the file are committed.
In general, applications should not mix DDL (Data Definition Language) operations like Create
Index or Drop Index and data updates within a single transaction.
Fast Answers to Common Questions
NetWare C Interface for DOS
Q - When I am running IPXODI v2.0, GetServerAddressTable() and
GetServerNameTable() return empty information buffers. The exact same calls function properly
under IPXODI v1.2. What should I do?
A - This situation is the result of a known problem with IPXODI v2.0 that will be
fixed in the next release. Until then, if you need to use these calls, use IPXODI v1.2.
Q - The documentation for the NetWare C Interface for DOS for
BroadcastToConsole(), CloseMessagePipe(), and GetBroadcastMessage() shows an error code
"253 (0xFC) MESSAGE_QUEUE_FULL". However, decimal "253" does not equal hex "FC."
A - The hex value is correct. The decimal value should be "252."
Tip The ScanDirEntry() And ScanFileEntry() calls do not return the
originating/owning namespace of a file or directory entry. To return this information, substitute
the NetWare v3.x system call ObtainFileOrSubdirectoryInformation() using the F2 interface. For
example code demonstrating this call, contact the Developer Support Group.
NetWare C Interface for Windows
Q - Is it possible to login and logout of a NetWare server from a Windows 3.1 DOS
box?
A - In order to log in and out of a NetWare server multiple times from a DOS
window, several conditions must be satisfied:
- The shell (IPX/ODI and NETX) must be loaded prior to starting Windows.
- VIPX.386 should be version 1.13 or later.
- Set NWShareHandles = TRUE to share drive mappings among DOS sessions. This
parameter is in the [NetWare] section of the Windows SYSTEM.INI file.
- A path must be maintained to the \LOGIN subdirectory of a NetWare server.
Q - When programming under Windows v3.1 using the NetWare C Interface for
Windows SDK v1.3, the error message, "SPX_NOT_INSTALLED," may be returned when
calling the function SPXInitialize(). Similarly, the error message, "IPX_NOT_ INSTALLED,"
may be returned when calling IPXInitialize().
A - To prevent these error conditions, make certain that you are using the appropriate
versions of the following files:
- IPX.COM v3.10 and above or IPXODI.COM v 1.20 & above
- VIPX.386 v 1.13 and above
- NWIPXSPX.DLL v1.31 and up
NetWare Client SDK
Q - Working with the NetWare v4.0 Client SDK, the NWCalls DOS Client Calls don't
seem to function. Am I forgetting something?
A - The NWCalls APIs require a call to NWCallsInit() before they will function
properly. NWCallsInit() initializes the double byte tables, as well as other lower-level interface
functions.
NLM SDK for NetWare v4.0
Q - How can I make my NLM's screen look like a standard Novell NLM screen?
A - Use the NWSNut libraries that are included with the NLM SDK for NetWare
v4.0.
WATCOM C/386
Q - I am using WATCOM C/386 v9.0 and the WLINK linker will not export symbols
from my NLM. What should I do?
A - Patch the v9.0 linker up to 9.01d, to fix this problem. Patches for WATCOM
C/386 are available from WATCOM's BBS at 519-884-2103.
Network C for NLMs
Tip In the Network C for NLMs v2.0(d) documentation, the example for
AIOAcquirePort() passes the hardwareType, boardNumber, and portNumber as integers.
However, doing so can result in a server abend. To fix the example, pass the hardwareType,
boardNumber and portNumber in as pointers to integers.
NetWare Btrieve
Tip The new NetWare Btrieve v6.0 operation 42, to control Continuous
Operations on a Btrieve file, can only be called from an NLM application, and not from a
workstation application.
Q - How can I create Data Definition Files (.DDF) files to work with third-party
products that requires them?
A - You can obtain these .DDf file in two ways:
- The software company who sold the product should be able to provide the .DDF
with their software.
- Use Xtrieve PLUS, XQL or NetWare SQL to create the .DDF files.
A special supplement to Novell's Professional Development Series BULLETS
Bundle Up for 1993
You've probably already purchased some warm-weather gear, but have you purchased the
development tools you'll need to make it through the winter?
Since your development efforts sometimes require more than one Novell development tool as
well as other Novell products, Novell has designed development tool bundles. These bundles
provide you with everything you need to develop specific types of applications for the NetWare
platform, including tools and comprehensive documentation that explains how the components
of the bundle work together, installation, service and support, and licensing issues.
Tool bundles are especially useful for new developers or developers new to a particular type of
application development. After purchasing a single tool bundle, you can begin developing your
application immediately.
Tool bundles are currently available for network management, NetWare 4.0 client/server
application development, and distributed desktop application development using Novell's TCP/IP
protocol. The specific bundles offered are:
- LAN WorkShop
- NetWare 4.0 tool bundle
- NetWare Management System tool bundle
LAN WorkShop
With the LAN WorkShop, Novell consolidates its TCP/IP development tools into one
package. This bundle includes:
- LAN WorkPlace for DOS Toolkit
- LAN WorkPlace for OS/2 Toolkit
- LAN WorkPlace for Macintosh Toolkit
- Enhanced version of NetWare Transport Independent Remote Procedure Calls (TIRPC)
SDK
All toolkits included with the LAN WorkShop provide both development tools and
end-user software.
The LAN WorkPlace for DOS Toolkit allows you to use TCP/IP to build custom applications
compatible with Novell's LAN WorkPlace for DOS v4.1. The toolkit software allows you to
write DOS, DR-DOS, and Windows applications that use the Novell TCP/IP protocol stack for
DOS and Windows via an industry-standard 4.3 BSD socket library API. Applications using
TCP/IP gain access to a wide variety of enterprise computing resources, such as PCs,
Macintoshes, VAX minicomputers, IBM mainframes, and UNIX workstations.
The LAN WorkPlace for OS/2 Toolkit v3.0 provides the necessary tools for developing OS/2
v2.0 16-bit and 32-bit industry-standard 4.3 BSD socket applications that run with the LAN
WorkPlace for OS/2 v3.0. The toolkit includes the LAN WorkPlace for OS/2 end-user program,
a TCP/IP stack for building applications that access TCP/IP resources, and requesters for OS/2
v1.3 and v2.0. Applications you develop using this tookit operate with other Novell products that
use the LAN WorkPlace for OS/2 APIs.
The LAN WorkPlace for Macintosh Toolkit v1.3 allows you to build applications that use the
APIs provided in the Novell TCP/IP for Macintosh (part of the LAN WorkPlace for Macintosh
product) or the Apple Macintosh TCP. The Toolkit also provides the necessary development
support for building HyperCard stacks that use TCP/IP.
The last component of the LAN WorkShop is the new TIRPC SDK, version 1.1, which is based
on the Solaris Open Network Computing Plus TIRPC model from SunSoft, Inc. The TIRPC
libraries allow programs to make function calls that can be transported across a network using
either TCP/IP or IPX, freeing developers from having to know the semantics of the underlying
network.
NetWare 4.0 Tool Bundle
The NetWare 4.0 tool bundle provides all the necessary tools for developing client and
server applications for the NetWare 4.0 platform. Products in this tool bundle include:
- Pre-release version of the NetWare 4.0 operating system
- NLM SDK for NetWare 4.0
- NetWare Client SDK
- WATCOM C/386 compiler and tools
- LANalyzer for Windows
With this bundle, you can take advantage of all the new features of NetWare 4.0 in your
application development. These features include (but are not limited to) NetWare Directory
Services (NDS), auditing, memory protection and management, file compression, data migration,
core OS process management, media manager, international language enabling, NCP (NetWare
Core Protocol) extensions, and backward compatibility with NetWare 3.x.
The NLM SDK for NetWare 4.0 features the NLM library of APIs for NetWare 4.0; the
NLM transport interfaces for multiprotocol support in NetWare 4.0; NWSHELL NLM, which
provides DOS-like commands that can be executed on the server; a complete set of
documentation; and support for WATCOM compiler v9.0 and higher.
The NetWare Client SDK contains software and documentation for developing DOS,
Windows, and OS/2 client applications for NetWare 2.x, 3.x, and 4.0. The C libaries provided
with this kit have been developed as single set of source code wherever possible, allowing easy
application migration between the three supported desktop platforms.
The WATCOM C 32-bit Optimizing Compiler and Tools is also provided with the NetWare 4.0
tool bundle. Tools include a linker, debugger, execution profiler, utilities, documentation, and
two libraries: the C graphics library and the C library. The WATCOM compiler can be used to
write DOS, Windows, OS/2, and NetWare applications.
The last component in the NetWare 4.0 Tool Bundle, LANalyzer for Windows, is a powerful
Windows-based application for monitoring your network on a day-to-day basis, monitoring
long-term network trends, analyzing specific problems, and capturing network packets for
protocol analysis. It uses a "dashboard" graphical interface consisting of real-time dials depicting
network activity. In addition, LANalyzer for Windows lets you print station monitor data,
decoded packets, detail graphs, and trend graphs. LANalyzer for Windows installs on any
network PC, runs on Ethernet cards, and supports ODI drivers operating in promiscuous mode.
NetWare Management Tool Bundle
The NetWare Management tool bundle provides all the software and documentation
necessary for creating network management applications for NetWare. This tool bundle is based
on Novell's open network management architecture which allows applications to snap into
NetWare's Network Management Map (NMM) platform. The NetWare Management tool bundle
includes:
- NetWare Management System (NMS)
- Network C for NLMs
- LANalyzer for Windows
The NetWare Management System SDK includes the NetWare Management Map, and a
set of tools and interfaces with which you can create custom management modules that plug into
the NetWare Management Map.
The tools and interfaces consists of a set of Windows 3.x Dynamic Data Exchange (DDE)
interfaces to an SNMP server and alarm manager, a Btrieve-based database schema, a set of
graphical user interface (GUI) tools that let you represent network management indicators as
graphic elements, and an application integrator that allows you to create new NMS menu items
and network management objects.
The second tool in this bundle is the Network C for NLMs SDK, which fully supports
development in both the NetWare v3.1 and v3.11 environments. This SDK includes the NLM
library of APIs, NLM transport interfaces, the WATCOM C/386 Optimizing Compiler and
Tools, and the NLM Certification Kit.
The final component in this bundle is LANalyzer for Windows, a diagnostic tool that provides a
"dashboard" graphical interface that lets you monitor the network on a day-to-day basis, review
long-term network trends, analyze specific problems, capture protocol analysis, as well as print
station monitor data and graphs of network statistics.
You must be a member of a Novell Developers' Program to purchase these tool bundles.
New NetWare Client SDK Features Single Interface
The NetWare Client SDK, which started shipping in January 1993, features a single
interface for writing DOS, DR-DOS, Windows, and OS/2 client applications in the NetWare 2.x,
3.x, and 4.0 environments. The C libraries provided in this kit have been developed as a single
set of source code whenever possible, allowing easy application migration between the supported
desktop platforms.
This SDK includes a pre-release version of the NetWare 4.0 operating system, the client API
libraries, and an API documentation set. It will replace four existing Novell products: NetWare C
Interface for DOS, NetWare OS/2 Developer's Kit, NetWare C Interface for Windows, and
NetWare System Calls for DOS.
If you purchased NetWare C Interface for DOS, NetWare OS/2 Developer's Kit, NetWare C
Interface for Windows, or NetWare System Calls for DOS before September 12, 1992, you can
purchase the NetWare Client SDK for a special price for a limited time. If you purchased one of
these SDKs after September 12, 1992 and can show proof of purchase, you can receive the
NetWare Client SDK free of charge for a limited time.
You must be a member of a Novell Developers' Program to receive this SDK.
Changes to Network Management Tools
With NetWare v3.11, Novell shipped version 1.0 of the SNMP (Simple Network
Management Protocol) Agent. This release marked the beginning of the movement toward
managing NLMs through SNMP. A new version of the SNMP Agent (v2.0) and set of developer
tools is now available as a component of the NetWare Management System (NMS) SDK.
The NMS SDK allows developers to register NLMs with the SNMP agent for SNMP
manageability. These new SNMP Agent developer tools replace the NetWare Network
Management Toolkit. The SNMP Agent tools define how developers can register an NLM and
the SNMP MIB (Management Information Base) associated with the NLM and the SNMP Agent
on the server. Any SNMP management station can access the registered NLM's MIB by using
the SNMP Agent as a proxy agent for the developers agent. Developers benefit from the SNMP
Agent through its mechanism of using the NetWare platform for network management. End users
benefit since they have less to learn beyond NetWare and the usage of NLMs.
As part of Novell's ongoing commitment to SNMP and developers already using the NetWare
Network Management Toolkit, toolkit users will receive the NMS SDK as well as any future
updates.
You must be a member of a Novell Developers' Program to purchase the NetWare Management
System SDK.
Five New Development Tools Announced
At NetWorld Boston, Novell announced the availability of five NetWare-enabled third
party development tools:
- Two C++ compilers
- A FORTRAN compiler
- A tool that facilitates application connectivity
- A breakout switch and interface card for programming and debugging
The new compilers include the WATCOM C++ compiler, Draiken Software Inc.'s INTEK
C++ v2.1 32-bit compiler, and WATCOM FORTRAN 77/386 compiler.
Additional tools announced include NetWorks! Developer, a productivity tool that enables
developers to hot link DDE-enabled applications over Novell's IPX without learning any new
syntax or commands, and STOP!, a simple non-maskable interrupt generator that NetWare
developers can use in conjunction with debuggers or user programs.
For more information on these tools, developers should contact the individual third-party
companies as follows:
- WATCOM, Sales Department at (519) 886-3700 or (800) 265-4555
- Draiken Software, Inc. at (503) 222-5417
- Symbiotics, Inc. at (617) 876-3635 or (800) 989-9174
- Alpha Logic Technologies, Inc. at (206) 644-3094
SMF v71 SDK Meets MHS Developer Requirements
The NetWare SMF v71 SDK provides everything you need to develop applications and
gateways that provide messaging services in NetWare MHS environments, including access to
message routing and messaging directory services. NetWare SMF, the native API to Novell's
NetWare MHS product line, offers simplicity, reliability, and inherent multiplatform support.
The SDK documents the newest generation messaging API and builds on earlier versions to meet
developer needs for unlimited recipients, unlimited message size, expanded distribution lists, and
long names with hierarchical mulitpart workgroups.
This SDK includes one copy of the 20-mailbox version of NetWare Global Messaging (NGM),
one copy of the 100-mailbox version of NGM, and the SMF v71 Programmer's Reference. The
SMF v71 Programmer's Reference documents the messaging APIs.
NetWare SMF is currently used by over 900 commercial and corporate developers. Over 150
commercial applications and services are available for an estimated 2.5 million installed MHS
mailboxes. These messaging applications range from electronic mail and network fax service to
workflow, scheduling, and forms processing.
1993 Begins with New Novell Corporate Developers' Program
In response to the unique development, implementation, and maintenance requirements
developers encounter within large corporations, Novell will deliver the Novell Corporate
Developers' Program in the second quarter of 1993.
This program is designed to facilitate and accelerate the development of distributed applications
that support, exploit, and enhance the NetWare platform in the corporate environment. The
program will initially be available worldwide with local implementations in the U.S., U.K.,
France, and Germany, with additional markets to follow.
Membership in this program is available through an annual subscription and is targeted for large
corporations developing industrial-strength applications on the NetWare platform for internal
use. Members of the Novell Corporate Developers' Program are entitled to all the benefits
available through the Novell Professional Developers' Program, Univel Professional Developers'
Program with additional benefits such as project support, system assessment, additional products
and development tools, product support, and education.
Project Support
Each program member is assigned an account representative who is familiar with the
member's environment and project and who acts as a liaison to other groups within Novell and
Univel. In order to better determine product focus for corporate developers, members are also
invited to Novell and Univel technical forums, including executive briefings, focus groups, and
product strategy meetings. In addition, membership in the Novell Corporate Developers' Program
includes admission to BrainShare, Novell's annual technical conference.
Novell System Assessment
Members will be provided system assessment services by Novell's Consulting Services
(NCS). Upon request and at no additional charge, program members will be invited to review
their existing implementation, business and system needs, project priorities, goals and objectives,
and timelines with NCS engineering staff.
With the information from the program member, NCS engineers will use their experience and
knowledge of Novell's products to provide a project recommendation in the form of a statement
of work. This statement of work can be used as a roadmap by the program member to facilitate
their own development effort or to enlist outside consulting services through Novell's consulting
services group and partners.
Development Products and Tools
Members of Novell's Corporate Developers' Program are provided with a development
copy of Novell's NetWare 2.x, 3.x, or 4.0 or NetWare J, and a copy of UnixWare Personal
Edition.
Development copies of the NetWare operating systems are provided to members to facilitate
prototyping, development, and testing of new applications without impacting existing business
systems. Based on their particular development efforts, members may also select any ten Novell
SDKs from the full list of available SDK products including the UnixWare SDK bundled with
UnixWare Application Server.
Program members will also receive updates to any of the Novell products they select through the
program, ensuring that the application development effort for the NetWare platform is always
with the most advanced and current technologies.
Development Product Support
Novell's Developer Support Group offers Novell Corporate Developers' Program members
priority access to customer support representatives and support engineers. Support calls from
program members will be acknowledged within four hours (during normal business hours). In
addition, program members have access to an assigned technician for the duration of the support
incident.
Developer Education
The effective transfer of Novell expertise to developers is vital for successful product use
and for accelerating the application development timeline. As part of the program, members may
attend three Novell technical education development classes throughout the subscription year.
Ongoing Development Support
Ongoing development support is provided to Novell Corporate Developers' Program
members, including access to the NDEVREL forum on CompuServe, the Univel Developer
Bulletin board, admission to the Advisory Council meetings, Novell developer publications, and
all other services offered through Novell developer programs.
For More Information
For additional information on development tools, developer support programs, and the
Novell Corporate Developers' Program, call 1-800-NETWARE or 1-801-429-5588 (in the U.S.
and Canada), or contact your local international Novell office.
Novell Developer Education offers several courses for developers who use Novell's development
& database tools, including NetWare SQL, Btrieve, Xtrieve PLUS, and the NetWare Client APIs.
- 904: Btrieve: An Overview
- This new course provides a general overview of NetWare Btrieve v6.x and its new
features. It covers file structures, indexing, data integrity, record and file locking, caching,
operating modes, segmented keys, backward compatibility and utilities.
- 905: Programming with Btrieve
- This course has been enhanced to cover all Btrieve operations & environments. It provides
a complete introduction to Novell's server-based record manager. 50% of class time is spent in
programming workshops. Working knowledge of C, BASIC, Pascal, or COBOL required.
Prerequisite: 904: Btrieve: An Overview.
- 907: Xtrieve PLUS
- This course has been updated to include new features introduced with NetWare SQL v3.0.
It teaches developers to use Xtrieve PLUS as a Btrieve or NetWare SQL programming utility.
Trains users of Btrieve- or NetWare SQL-based database applications to work effectively with
this menu driven utility.
- 911: NetWare Database Administrator
- This new course gives a complete, hands-on look at installing and configuring NetWare
SQL and NetWare Btrieve. It covers the basics of ANSI Standard Structured Query Language
(SQL), focusing on NetWare SQL and key database features like security, referential integrity
(RI), database design, data normalization and performance.
- 912: Programming with NetWare SQL
- This new course is designed for developers and experienced network and database
administrators who will be developing NetWare SQL applications or enhancing existing Btrieve
applications with NetWare SQL. It provides an in-depth look at the functionality of NetWare
SQL and discusses optimizing database systems for development of efficient applications using
Novell database tools.
- 930: Developing NetWare Loadable Modules (NLMs)
- This course introduces C programmers to server-based application development in the
32-bit NetWare 3.x environment. It covers basic concepts for writing server-based C applications
that access the NetWare 3.x C library (CLib). Requires working knowledge of the C language.
- 940: NetWare Programming: Basic Services
- This new lab-oriented class (40 percent lab work) introduces NetWare programming
concepts. It covers topics such as bindery services, file system services, print services, queue
management, connection and file-server services, and accounting and synchronization services.
This class requires knowledge of the C programming language.
- 945: NetWare Programming: Protocol Support
- This new class covers protocol support features. It also discusses network programming
concepts and techniques for developing client-side applications, including Service Advertising
Protocol (SAP) IPX/SPX, diagnostics, NetBIOS, TLI, and Named Pipes. This class requires
strong knowledge of the C programming language.
To obtain information on pricing, location, scheduling, & course content for classes held in the
US, call 1-800-233-3382, 1-801-429-5508 or 1-800-NETWARE. Customers outside of the US
should call 1-801-429-5508. For information on availability, location, and prices of classes
outside of the US, contact your local Novell office.
Test your developing skills with the development products by taking our Fun & Facts quiz. (See
the end of this section for answers.)
1. What is the bandwidth of the current Token Ring technology?
A. Either 4 or 8 MB/sec.
B. Either 4 or 16 MB/sec
C. Either 8 or 16 MB/sec.
2. The NetWare C Interface for DOS function SaveDirectoryHandle() can be used to save
temporary directory handles.
A. True
B. False
3. What was the original name of the "Windows NT" operating system?
A. Windows v4.0
B. Windows II v1.0
C. OS/2 v3.0
4. Which file does NetWare SQL v3.0 use to store the names of the named databases?
A. NAMES.DB
B. DBNAMES.CFG
C. NAMEDDB.CFG
5. When a Btrieve file has a key of type Lstring, if the first byte is set to NULL and the rest
of the bytes in the key are not set to NULL, Btrieve does not treat that key as a NULL key.
A. True
B. False
6. Event Service Routines (ESRs) are supported in the (NLM) environment?
A. True
B. False
7. NetWare SQL v3.0 can access Btrieve files on both local and network drives.
A. True
B. False
FUN AND FACTS ANSWERS
1. B
2. B
3. C
4. B
5. A
6. A
7. B
Developer Support
Developers in the U.S. and Canada may contact Novell Developer Support via telephone, fax,
BBS or electronic mail via CompuServe, MHS or the Internet.
Voice
For both presales and postsales support, call Novell Developer Support between 8:00 a.m. and
5:00 p.m. Mountain Time at 1-801-429-5588. Many calls to Novell Developer Support are
passed to a software support engineer immediately. Calls to Novell Developer Support generally
will be acknowledged or answered within four hours.
Fax
If you prefer, you may contact Novell Developer Support via fax at 1-801-429-2990. Faxed
questions are acknowledged or answered within 24 hours.
Developer BBS
If you do not have access to either CompuServe or the Internet, send test cases to our BBS. Set
your communication software to N-8-1 and call 1-801-429-5836.
E-mail: CompuServe
Post your messages in the appropriate section addressed to Novell at 76701,171. These messages
will receive a response within 24 hours.
E-mail: MHS
You may direct your questions and comments to Novell Developer Support via Novell's Message
Handling Service E-mail facility. Address your messages to devsup@novell. These messages
will receive a response within 24 hours.
E-mail: Internet (SMTP)
An alternative method of contacting Novell Developer Support is through the Internet E-mail
system. Send your messages to devsup@novell.com. These messages will receive a response
within 24 hours.
NetWire on CompuServe
Novell's NetWire forum is open to all registered CompuServe subscribers. Through the
NDEVSUP forum, professional developers writing applications with Novell development tools
can gain access to information specific to Novell development. Support, patches, periodicals and
product information, as well as information on all of the programs and services provided for
Novell developers are accessible through this forum. Post your messages in the appropriate
section addressed to Novell at 76701,171. Technical questions will be acknowledged or
answered by Novell Developer Support within 24 hours.
Novell Products and SDKs
Novell products on the "Currently Shipping Developer Products" list (see page 15 of this
issue), including the Red Box Products, are available to Novell Professional Developer's
Program members. Call 1-800-RED-WORD (1-800-733-9673) or 1-303-894-4135 to order these
products or to receive additional information. To order other Red Box Products not listed,
contact your local Novell office or Novell Authorized Reseller.
DeveloperNet Labs
For information on DeveloperNet Labs development tools, education classes and product certification,
in the U.S. and Canada call 1-800-453-1267 ext. 5544 or 1-801-429-5544, or call your local
Novell office (see back cover of this issue).
Novell Developer Relations
Novell Professional Developers or those wishing to become members may contact Novell
Developer Relations via telephone, fax, or electronic mail via Compuserve, MHS or the Internet.
Voice
For general information or questions on Novell Developer Relations programs, in the U.S.
or Canada call 1-800-RED-WORD (1-800-733-9673). All others call 1-801-429-5281.
Fax
If you prefer, you may contact Novell Developer Relations via fax at 1-801-429-7207.
NetWire on CompuServe
Novell's NetWire forum is open to all registered Compuserve subscribers. Through the
NDEVREL forum, Novell Professional Developer's Program-related issues or general questions
may be posted. Through the NDEVINFO forum, customers who do not have products may post
pre-sales product information questions on all Novell SDKs.
E-mail: MHS or Internet (SMTP)
You may direct your questions and comments to Novell Developer Relations via Novell's
Message Handling Service E-mail facility. Address your messages to devprog@novell.com. Use
the same address when going through the Internet E-mail system.
Publisher: Mad Poarch
Editor: Kirk R. Humphries
Design: Creative Services, Provo
Contributing authors: Gaurang Amin
Linda Anderson
Michael Eisa
Neda Eslami
Jack Gumaer
Ross Hopson
Sudz Khawaja
Nancy Kromar
Matt Pinsonneault
Bob Quinlan
Clint McVey
Randy Reddy
Holly Roff
Mike Shoemaker
Aslam Tejani
Special thanks to the Developer Support, Development, Developer Relations, Product Marketing,
and Marketing Communications staff who contributed time and valuable input.
Novell, the N design, NetWare, Btrieve, XQL, LAN WorkPlace and LANalyzer are registered
trademarks; NetWare Loadable Module (NLM), NetWare Global Messaging, NetWare System
Calls for DOS, NetWare Runtime, NetWare SQL, NetWare Btrieve, NetWare C Interface for
DOS, NetWare System Interface Technical Overview, NetWare RPC, NetWare RPC 386,
NetWare LU6.2, Report Executive, NetWare MHS, NetWare Asynchronous Communication
Services (NACS), NetWare Management System, Professional Development Series, NetWare
3270 LAN Workstation and Xtrieve PLUS 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 is a trademark of Microsoft Corporation.
Apple, AppleTalk, HyperCard and Macintosh are registered trademarks of Apple Computer, Inc.
CompuServe is a registered trademark of CompuServe Corporation.
NFS and Solaris are registered trademarks, and SunSoft is a trademark of Sun Microsystems, Inc.
UNIX is a trademark of UNIX Systems Laboratories, Inc., a subsidiary of AT&T. Univel is
trademark of Univel, Inc.
(c) 1993 Novell, Inc. All rights reserved.
Professional Development Series
BULLETS
JANUARY 1993
|
