Pawel has been programming networks for the past five years. He lives in southern Sweden and works as an independent developer and consultant specializing in the NetWare environment. You can reach him on CompuServer at 72133,2232 or by phone at +46-40116759.
Introduction
Since launching the "Undocumented Corner" in March 1993, I've focused entirely on Microsoft. As the major force in PC software, this fixation on Microsoft is appropriate. Some might even charge that Microsoft uses its undocumented interfaces to shore up a near-monopoly position. If it weren't for all the undocumented interfaces used by so many popular applications, almost anyone could create clones of DOS and Windows and wade into the Microsoft-dominated PC operating-systems market.
However, Microsoft isn't the only company that holds back information vital to third-party developers. Novell, Microsoft's chief competitor for PC operating systems and an apparently active supporter of the Federal Trade Commission's three-year investigation of Microsoft trade practices, has among network developers a reputation for failing to document vital interfaces in its NetWare operating system. In fact, practically everyone I've spoken to on this subject says the same thing: "Novell? When it comes to undocumented interfaces, they're even worse than Microsoft."
It is odd, therefore, for Novell to complain of unfair treatment at the hands of Microsoft. In the arena it dominates, and almost monopolizes--network operating systems--Novell appears to behave in much the same way as Microsoft does in its home turf. Thus, Novell is what the law sometimes calls in pari delicto or "in equal fault."
A chief example is the NetWare Core Protocol (NCP), the subject Pawel Szczerbina tackles this month. NCP is the packet interface that the NetWare workstation shell, such as NETX.EXE, uses to send requests to a NetWare file server. NCP is similar to the Server Message Block (SMB) interface used in PC-NET, LAN Manager, and various other unsuccessful Microsoft networking products, except that Microsoft, to its credit, has made the SMB specification available (on CompuServe, type GO MSNETWORKS and download the 250K file SMBSPE.ZIP which, however, has not been updated since November 1990).
Novell claims that NCP is not undocumented but rather "proprietary." In fact, Novell last year began licensing NCP to third parties. A July 6, 1992 Novell press release claims that "NCPs are a documented set of procedures used by NetWare to accept and respond to requests by workstations on the network. Under the new program, licensees can develop NCP-compatible Service Requesters and/or Service Providers."
However, the price appears to range from $15,000 to $30,000. In the words of Rob Young, director of marketing for Novell's NetWare Systems Group, "Some people make a connection between openness and free, and we don't necessarily think those things go hand in hand_. We didn't do this to boost revenues; the fee is for support and certification" (see "Novell Gives Green Light to Licensing NetWare Core," PC Week, July 13, 1992). Yeah, right. If the price isn't a stumbling block for you, contact the NetWare Technology Licensing Program (800-733-9673).
Information on NCP is also scattered in a number of books, including Carl Malamud's Analyzing Novell Networks (VNR, 1992), Mark Miller's LAN Protocol Handbook (M&T Books, 1990), and even in Novell's Guide to NetWare LAN Analysis (Sybex, 1993) by Laura Chappell, a Novell employee. Chappell explains that "Novell does not publish details regarding its NCPs because the information is 'Novell Confidential.' The NCP codes in this chapter, however, were taken from the LANalyzer for NetWare screens, which provide clear, accurate decodes of all NetWare NCP functions and subfunctions."
Indeed, LAN protocol analyzers are the major source of information on NCP. In addition to Novell's own LANalyzer, other NCP-aware analyzers include The Sniffer from Network General (Menlo Park, California) and The Snooper from General Software (Redmond, Washington). The Snooper comes with complete C source code, including Steve Jones's NCP.C.
Related to NCP is another piece of undocumented NetWare, the so-called F2 interface. The NetWare workstation shell extends INT 21h to provide many NetWare-specific functions. While many of these extensions are documented by Novell, some are not, including INT 21h AH=F2h, which can be used to issue "raw" NCPs to the file server. Novell only documents a tiny subset of this, INT 21h AX=F244h, to erase files. If you examine Table 4 of Pawel's article, you will note that 44h is the NCP Erase Files function. In other words, Novell officially documents only one NCP function--Table 4 lists over 300! The F2h interface is a good way to issue raw NCPs to the server, and Novell recommends it as the primary way to do this for certain tasks. Also, there is a file on CompuServe (GO NOVLIB) called SC3X0n.EXE (where n is a number that increments as they update it) that shows how to use certain "undocumented" NCPs on NetWare 3.11. Most of these code samples use the F2h interface. However, all of the samples bear a big (yet ridiculous) disclaimer that says: "This software is considered pre-release and may be used at your own risk and has been provided due to the many requests of our customers. Support for this module will be provided at the sole discretion of Novell, Inc." Finally, there's a new Client API for Assembly (now in beta) which covers more F2h calls, though it doesn't go into detail about how F2h calls translate into NCP transactions on the wire.
Pawel's article is a first look at the subject of undocumented NetWare. The second edition of Undocumented DOS, which I am just finishing now (and which should be in bookstores in November or December 1993), will have a new section on NetWare, including details on the NETX shell and the F2 interface. Even better, Tim Farley is actively working on a book, Undocumented NetWare, to be published in early 1994 as part of a series I edit for Addison-Wesley. Tim contributed major additions to Pavel's article. Interestingly, the idea for this book first came from an engineer at Microsoft. With Microsoft's accusations against Novell, and Novell's accusations against Microsoft, the safest thing is probably to assume that they're both telling the truth. Our friend at Microsoft says of NCP, "who knows how many inventions would be enabled by publishing this."
To really use any of the information Pawel provides here, you need to download his NCPTEST source code (see "Availability," page 3).
Right now it looks like future "Undocumented Corners" will look at low-level aspects of Windows, such as undocumented DPMI, the Virtual Machine Control Block structure, Instance Data lists, and so on. Another possibility is the fascinating topic of undocumented NT, though I find it difficult to be enthusiastic about an operating system that requires 16 Mbytes of memory. Please send your comments and suggestions to me on CompuServe at 76320,302 (that's [email protected] from the Internet).
The NetWare Core Protocol (NCP) is a packet format that client workstations on the network use to communicate with a NetWare server. NCP provides services such as file manipulation, message sending, transaction processing, printing, and the like.
In a DOS-based workstation, the NetWare shell (NETX.EXE, NET3.EXE, VLM. EXE, and so on) is responsible for establishing and maintaining an NCP session with a file server. The NetWare shell also provides a DOS-like interface for applications to use; higher-level APIs, like the NetWare C Interface, use this low-level interface.
Requests originating from applications, regardless of the API used, are eventually converted by the NetWare shell to NCP packets and sent to the server. Responses from the server are converted back to the format of whatever API the application is using. Some of the functions specified in the different interfaces may end up sending several NCP packets. There are also several calls that access local data within the workstation shell and consequently never generate any requests to the server. But, in general, almost everything in NetWare rests upon NCP.
NCP isn't just for communication between users and file servers. Print servers also rely on NCP, as can any NetWare object type. Regardless of the physical implementation of the print server (VAP, NLM, EXE, or a standalone device), at some point it has to use NCP to access the NetWare queue management system; that is, check for data present, read queue data, and so on. It can then distribute the print data to the printers (in case they are not directly connected to the print server itself) using any protocol it likes. Novell's own PSERVER is a good example: It uses NCP to log in to the server and access queues, and uses a separate RPRINTER/
NPRINTER protocol to communicate with remote printers.
In the OSI model, NCP covers the transport and session layers, and is conceptually similar to the SMB protocol in Microsoft's LAN Manager. You can think of NCP as an operating-system interface or collection of remote procedure calls. The difference, compared to a traditional operating-system interface, is that here, the OS itself resides on a different physical machine--the NetWare server. NCP is a client/server or distributed interface.
NCP uses Novell's Internetwork Packet Exchange (IPX) as the underlying network-level protocol. IPX is a connectionless (datagram) transport service that does not guarantee packet delivery. The session control and packet error checking are performed by NCP.
Now, you may ask: Why should I care about the undocumented NetWare Core Protocol? Isn't programming using published and documented Novell APIs, like the NetWare C Interface, the recommended way to develop software in this environment?
It certainly is, as this makes your programs portable to different client platforms and frees you from having to write your own NCP requester. Nevertheless, there are several reasons why NetWare developers have long wanted information on NCP.
Understanding what happens between the NetWare shell and a file server may help you to more quickly locate problems, especially in complex network environments involving several pieces of software. Once you know what NCP traffic is produced by the standard NetWare API calls, you may find other and more efficient ways to accomplish the same tasks. Also, some software, such as programs that boot the workstation from the file server, can't be implemented without knowing how NCP works.
If you want to understand NCP, you'll need some kind of network traffic analyzer to see what happens on the wire. LAN analyzers such as The Snooper, The Sniffer, or NetWare's LANalyzer are essential tools for developing software in networked environments.
This article explains the basic principles behind NCP. Recent additions to NCP like packet signing, Burst Mode, and Large Internet Packets aren't covered. NCPTEST.C, a sample program that shows how to access services of a NetWare file server is available electronically (see "Availability," page 3). NCPTEST requires that IPX be loaded, but does not require Novell's NetWare shell. The NetWare shell typically occupies 30--50 Kbytes, so in some specialized applications NCP programming might even be a good low-memory alternative to using the shell. If you compile NCPTEST using Borland C++ 3.1, use command line: bcc -ml -a -K ncptest.c ipxint.c ncpint.c. (The appropriate memory model is very important.) Since I use Borland's screen I/O library, NCPTEST isn't directly generic and you'll have to make changes before compiling with another compiler. NCPTEST requires a NetWare 2.1x or higher server.
NCPTEST finds the nearest NetWare server, and sets up three separate connections to it, all under the same user ID and password. This is normally impossible under the regular DOS client software for NetWare, so it's a good example of something you can do by going directly down to NCP and ignoring the shell. The program also displays the state as it builds up the connection, then sits in an "idle" state until you press any key to kill each connection.
Before you kill the program, go to another station that's logged into the same server, and execute the Novell command USERLIST /A. This shows all the users logged in, and their addresses. You'll see three separate connections being taken up by the user specified on the NCPTEST command line, but all of them have the same net address. This is normally impossible in NetWare--you can log in more than once, but not from the same machine.
NCP is a half-duplex, request/re-sponse protocol. The client (generally NETX.EXE or some other NetWare workstation shell) is the active side: It initiates the communication process by sending a request. The server (generally the NetWare file server) processes the request and responds with a reply. The client then processes the reply and possibly issues a new request. For example, the client may issue a request to open a file; the server would then send a response indicating whether the file could be opened. The client can have only one request (packet) outstanding at any time. The client must wait for a response before sending the next request (this is not true for Burst Mode NCP).
Since NCP uses an unreliable network protocol for delivery, it must ensure that the packets are delivered in sequence and without duplication. The client accomplishes this by assigning a sequence number to each request. The server is expected to respond with a packet containing the same sequence number. If it does, the client increments the sequence number by one and transmits the next request. Responses having incorrect sequence numbers are discarded by the client. It is legal for a client to resend a request to which the server already replied, that is to resubmit the latest request. In this case, the server assumes that the reply got lost on its way to the client and reexecutes the request.
If the server does not respond at all to a request, the client resubmits the same request a number of times before assuming that the server is unreachable. This is necessary because of the unreliable underlying transport protocol and media. Because of a busy network, packets may never get sent. They may get dropped by a router, malformed on their way to the destination, and so on. It's up to the client to choose the number of, and time between, retries. For instance, the DOS client, NETX, has a number of parameters in its INI file (NET.CFG) which control the client's NCP timeout behavior, including NCP SET TIMEOUT= and NCP TIMEOUT MULTIPLIER=. Then, if the server can't immediately respond because it is busy, it will send a special packet (called "Positive Acknowledge") to the client. This indicates that the request is being processed; the client should continue waiting for the reply. Such a packet has the same sequence number as the request that caused it. The server will first send when it receives a duplicate request (because the client times out) and the server still processes that request. (Novell calls this "Positive Acknowledge" packet "Request Being Processed," at least in LANalyzer traces.)
The server also needs to know if a client is still alive. If the client stops sending requests without properly terminating the connection, the server must know whether the person operating the workstation temporarily stopped using it or if the station has been turned off. Since each workstation occupies at least one user connection at the server, there's a possibility that a number of workstations could unnecessarily take up connections that could be made available for others to use. After a period of workstation inactivity, the server sends a watchdog packet to the client, asking if the client is still active. If the client doesn't respond, the server will send a number of watchdog packets, at regular intervals. Should none of the watchdog packets produce a reply from the client, the server will break the corresponding connection and make it available for other workstations.
Except for the information exchanged on the watchdog socket, NCP uses no special system packets devoted to keeping the session alive, confirming successful arrival of data packets, and the like. This makes NCP an efficient protocol. However, the request/response nature of the protocol makes it slow on WAN links where the time between a request and a response can be considerable. To remedy this, Novell has introduced Burst Mode NCP which makes NCP a windowed protocol, able to send several packets in one direction before requiring a reply. Burst Mode is currently used only for reading and writing files.
Regardless of its type, an NCP packet occupies the data portion of an IPX packet. All NCP packets, except for the Burst Mode NCP, have a structure like that in Tables 1 and 2.
A request packet starts with a 16-bit Packet Type field, which indicates the request type. Request types are listed in Table 3. Of the six request types shown, the three most important are type 0x1111 (Allocate Slot Request), used when creating a connection; type 0x2222 (Request), used for ordinary NCP requests; and type 0x5555 (Deallocate Slot Request), used when terminating a connection. (Novell LAN alyzer's terminology for 0x1111 and 0x5555 is "Create Service Connection" and "Destroy Service Connection."
The client sets and increases the Packet Sequence Number field , as explained earlier.
The Client Task Number in Table 1 identifies the client task that issued the request. Each connection may have several tasks (programs) executing on the same connection. The server tracks resources like semaphores, file locks, and so on, for each of the client's tasks. When the client issues an End-of-Job command, the server releases resources belonging to that task.
Together, the two Server Connection Number fields constitute a 16-bit connection number, assigned by the server when creating a connection, and later exchanged between the client and the server in all requests and replies. Until recently, the connection number high byte was always 0 in all commercially-available versions of NetWare, none of which allow more than 250 users to be on the server at once and therefore never need a connection number over 250. However, Novell has been for years selling to special customers a 1000-user version of NetWare 3.11. Unfortunately, Novell didn't publicly document how the 1000-user API differs from the older APIs which use a single byte for a connection number. This is being resolved this year, with the retail version of NetWare 4.0, which supports 500 and 1000 users.
The Function Code in Table 1 indicates which NCP function is to be executed by this request (see Table 4, page 128). This field may be followed either directly by the Request Data field, or by the subfunction length and code.
The Subfunction Length, if present, indicates the length of the following data, excluding this field. If this field is present, the Subfunction Code field is also present. Some commands, such as the Transaction Tracking System (TTS) and semaphore handling functions, lack the length field. In this case, the subfunction code directly follows the function code.
The Request Data field in Table 1 carries zero or more bytes of function/subfunction dependent data.
A reply packet also starts with a 16-bit Packet Type field (see Table 2). The allowable values are 0x1111 (Reply), used for the normal NCP replies, and 0x9999 (Positive Acknowledge), used to indicate that a server is busy processing a request.
The reply Sequence Number carries the sequence number of the corresponding request.
The reply Completion Code field (Table 2) indicates whether or not the request executed successfully. A 0 indicates success; any other value usually indicates an error. Novell's NetWare System Calls for DOS lists error codes. The same completion code can take on different meanings, depending on which function was executed.
The Connection Status field indicates the status of the connection itself. The lower four bits should be interpreted as a value between 0--15: 0 means that the connection is alive; any other value indicates that a connection is in error and is no longer valid. Bit 4 set indicates that the server is down. Bit 6 set means the workstation has a message waiting at the server.
The NCP client is responsible for creating a connection with the server. A workstation may have several simultaneous NCP connections open to the same server or to different servers. Each NCP connection is equivalent to a user connection at the file server. A full connection address consists of the 4-byte network number, 6-byte physical node number, and 2-byte IPX socket number. A client needs to open three IPX sockets for every NCP connection it wishes to maintain. New additions to NCP, like the Burst Mode and Large Internet Packets, require additional sockets.
The client's socket numbers must be consecutive: If the first socket is 0x4003, the second and third should be 0x4004 and 0x4005. Each socket can be considered a communication channel, independent of other sockets, on which conversation with the server takes place.
The first socket is used to exchange NCP requests and replies. The destination socket at the file server is always 0x0451. NCP's IPX packet type is 0x11. The second socket is a watchdog socket, used by the file server to determine whether the client is alive. The third socket is a message socket that receives message notifications from the server.
Before the client can create a connection to a server, it must know the server address; that is, its network, node and socket numbers. Given a server name, one can use the Service Advertising Protocol (SAP) to obtain the server address. For an example, see the SAPGetNearestServer() function in NCPINT.C (available electronically).
Once the client knows a server address, it uses an NCP Allocate Slot Request packet to establish the connection. The client must set the packet type to 0x1111. Also, it should fill the connection bytes with 0xFF to indicate that the client does not yet have a connection. The sequence number and function number should be set to 0. The task number may be assigned any value.
The server will respond with a packet type 0x3333. The client should examine the completion code and connection status for possible errors before proceeding. For example, the server may be out of user connections. Provided that the request is successful, the connection bytes in the reply packet will contain the file server connection number the client has been assigned. This number, which does not change during a lifetime of a connection, must be supplied in all subsequent requests to the server until the connection is terminated. The function NCPAttachToFileServerWithAddress() in NCPINT.C demonstrates the connection process.
After creating the connection, you should also negotiate the maximum NCP packet size that can be used. The two sides inform each other of their respective maximum receive buffer sizes. The smaller of the two will be used by both the client and the server. The value returned by a NetWare server is 1024 if there are no routers between the server and the client, otherwise it is 512.
The procedure described above is basically what happens behind the scenes whenever a NetWare shell loads, or a program issues the NetWare AttachToFileServer call. At this point, if everything worked as expected, the client has created a connection at the server. The client still needs to log in, however, because by itself having a connection provides only a very limited access to the server resources. You can use the NetWare FCONSOLE utility to verify that a connection has been created. On a 3.x server you'll see a string "NOT-LOGGED-IN" as the user name; this indicates that a connection exists, but no one has yet logged in. No indication is given on 2.x servers.
Any NetWare object can log in to a file server. The most common object is the user object (0x0001), but other types of objects (such as job and database servers) also frequently log in.
There are two ways to log in to a server: using unencrypted or encrypted passwords. Unencrypted passwords are visible on the network and present a security threat. Encrypted passwords, supported by NetWare 2.15c and higher, are encrypted at the workstation and not visible as plain text on the network.
Briefly, encryption of the passwords works as follows: The client requests an encryption key from the server (NCP request 0x17 0x17; see Table 4). It then asks the user for the plain password and encrypts it using the key and the object's 4-byte ID number obtained using the GetBinderyObjectID request (0x17 0x35). The encrypted password is then sent to the file server for verification. For each login attempt, the client needs to request a new (different) encryption key from the server.
NCPTEST.C and NCPINT.C (available electronically, see page 3) use encrypted passwords. That part of the source code is a direct translation of a Pascal program written by Barry Nance. (See "Automatic NetWare Log-ins: How to Log into NetWare from Your Programs without User Interaction," Byte, March 1993. The program is available as ELOGON.ZIP in the BPASCAL forum on CompuServe, and through other sources. According to Nance's article, he got the algorithm from Terje Mathesen's NETWARE.PAS code on BIX.)
Once logged in to a server, the client has access to its resources as specified by the client's privilege level. To use these resources, you need to know the format of the NCP functions you plan to use. Table 4 lists over 300 NCP function and subfunction codes. It isn't a complete reference, but rather a bare listing of the most used calls. To use any of these calls, you'll need to know the call's specific packet format. Some sample formats are provided in NCPINT.C (available electronically).
Often, the exact format of a request and reply can be inferred from Novell's NetWare System Calls for DOS. The request buffers described in that document are to be appended directly after the NCP request header, starting either at the Subfunction Length or at the Request Data field, depending on the type of function. The reply buffers, without the reply length field, normally start at the Reply Data field in the NCP reply packet.
Also, a careful study of the source code and header files provided with the NetWare C Interface helps to understand NCP packet formats. Some NCP functions, however, are not directly accessible through standard APIs and consequently are not described in easily available documents. One way to learn about the format of such packets it to use a protocol analyzer capable of decoding NCP. Another, if you can afford it, is to license NCP documentation directly from Novell.
When the client no longer needs a connection, it should free it, thus making its corresponding server connection available for others to use. To accomplish that, the client sends a NCP Deallocate Slot Request to the server. (According to LANalyzer, "NCP Deallocate Slot" is "Destroy Service Connection.") Such a request looks like an ordinary NCP request, except for the Packet Type field, which should be set to 0x5555 (see Table 3). The Function Code field should be set to 0; no subfunction code is present. Upon successful execution of this request, the connection is invalid.
The format of the watchdog request and reply, mentioned earlier, differs from that of normal NCP packets. The file server socket from which these packets originate is dynamic, often 0x4001. The IPX packet type varies, although it usually is 0x11 or 0x00. The NetWare 3.1x file servers have three setable parameters for watchdog packet configuration: "Delay Before First Watchdog Packet," "Number Of Watchdog Packets," and "Delay Between Watchdog Packets."
When a server has a message for a client, it informs the client of the message's presence by sending a packet to client's message notification socket. The client is expected to issue a NCP Get Broadcast Message request (0x15 0x01) to read the message itself, which stops the server from sending more notifications. The client does not have to read the message immediately; the server will continue sending notification packets approximately once a second. Also, all replies originating from the server will set bit 6 in the Connection Status until the client reads the message. The file server socket from which these packets originate is dynamic, often 0x4001. The format of the watchdog and message packets can be found in NCPTEST source code.
Using NCP could enable a whole range of innovative NetWare programming. Some possibilities include building your own simple NetWare protocol analyzer, writing an asynchronous version of the NetWare C interface, connecting client hardware to NetWare, writing replacement workstation shells, or perhaps (like Ornetix Technologies' SerView) even writing your own NCP server, only implementing a subset of the NCP functionality.
Chappell, Laura. Novell's Guide to NetWare LAN Analysis, Novell Press, ISBN 0-7821-1143-2.
Rose, Charles G. Programmer's Guide to NetWare, McGraw-Hill, ISBN 0-07-607029-8.
Novell, NetWare System Calls for DOS.
Novell Network Encyclopedia. A CD-ROM containing several technical bulletins and application notes.
Nance, Barry. "Automatic NetWare Log-ins: How to Log into NetWare from Your Programs without User Interaction," Byte, March 1993.
Copyright © 1993, Dr. Dobb's Journalby Andrew Schulman
Client-server Communications
NCP Packet Formats
Creating an NCP Connection
Logging In
NCP Conversation
Closing the Connection
The Message Socket
Where From Here?
References
Table 1: NCP request packet.
<B>Packet Description</B>
byte 0, 1 Packet type, 2 bytes (see <a href="#0349_0010">Table 3</A>).
byte 2 Packet sequence number, 1 byte.
byte 3 Server connection number, low, 1 byte.
byte 4 Client task number, 1 byte.
byte 5 Server connection number, high, 1 byte.
byte 6 NCP function code, 1 byte (see <a href="#0349_0011">Table 4</A>).
byte 7, 8 Subfunction length, 2 bytes, hi/lo (optional).
byte 9 NCP subfunction code, 1 byte (optional; see <a href="#0349_0011">Table 4</A>).
byte 10... Request data (optional).
Table 2: NCP reply packet.
<B>Packet Description</B>
byte 0, 1 Packet type, 2 bytes (see <a href="#0349_0010">Table 3</A>).
byte 2 Packet sequence number, 1 byte.
byte 3 Server connection number, low, 1 byte.
byte 4 Server task number, 1 byte.
byte 5 Server connection number, high, 1 byte.
byte 6 Completion code.
byte 7 Connection status.
byte 8... Reply data (optional).
Table 3: NCP packet types (*How Novell LANalyzer refers to packet).
0x1111 Allocate Slot Request (*Create Service Connection).
0x2222 Request (see <a href="#0349_0011">Table 4</A>).
0x3333 Reply.
0x5555 Deallocate Slot Request (* Destroy Service Connection).
0x7777 NCP Burst packet (request/reply).
0x9999 Positive Acknowledge (*Request Being Processed).
Table 4: NCP functions and subfunctions.
<B> Function Subfunction </B>
<B>Function Name Code Code </B>
Abort Servicing Queue Job And File 0x17 0x73
Add Audit Property 0x58 0x02
Add Bindery Object to Set 0x17 0x41
Add Trustee to Directory 0x16 0x0D
AFP Alloc Temporary Dir Handle 0x23 0x0B
AFP Create Directory 0x23 0x01
AFP Create File 0x23 0x02
AFP Delete 0x23 0x03
AFP Get Entry ID From Name 0x23 0x04
AFP Get Entry ID From Netware Handle 0x23 0x06
AFP Get Entry ID From Path Name 0x23 0x0C
AFP Get File Information 0x23 0x05
AFP Open File Fork 0x23 0x08
AFP Rename 0x23 0x07
AFP Scan File Information 0x23 0x0A
AFP Set File Information 0x23 0x09
Allocate Permanent Directory Handle 0x16 0x12
Allocate Resource 0x0F None
Allocate Special Temporary Directory Handle 0x16 0x16
Allocate Temp NS Dir Handle 0x57 0x0C
Allocate Temporary Directory Handle 0x16 0x13
Allow Task Access To File 0x4E None
Attach Queue Server To Queue 0x17 0x6F
Broadcast to Console 0x15 0x09
Change Auditor Password 0x58 0x04
Change Bindery Object Password 0x17 0x40
Change Bindery Object Password Encrypted 0x17 0x4B
Change Bindery Object Security 0x17 0x38
Change Property Security 0x17 0x3B
Change Queue Job Entry 0x17 0x6D
Change Queue Job Position 0x17 0x6E
Change To Client Rights 0x17 0x74
Change User Password 0x17 0x01
Check Audit Access 0x58 0x05
Check Audit Level Two Access 0x58 0x16
Check Console Privileges 0x17 0xC8
Check Pipe Status 0x15 0x08
Clear Connection Number 0x17 0xD2
Clear File 0x07 None
Clear File Set 0x08 None
Clear Logical Record 0x0B None
Clear Logical Record Set 0x0E None
Clear Physical Record 0x1E None
Clear Physical Record Set 0x1F None
Clear Volume Restrictions 0x16 0x22
Close And Queue Capture File 0x11 0x01
Close Bindery 0x17 0x44
Close File And Start Job Queue 0x17 0x69
Close Message Pipe 0x15 0x07
Close Old Auditing File 0x58 0x14
Close Semaphore 0x20 0x04
Commit File 0x3D None
Create Bindery Object 0x17 0x32
Create Directory 0x16 0x0A
Create New File 0x4D None
Create Property 0x17 0x39
Create Queue 0x17 0x64
Create Queue Job And File 0x17 0x68
Deallocate Directory Handle 0x16 0x14
Deallocate Resource 0x10 None
Delete Bindery Object 0x17 0x33
Delete Bindery Object From Set 0x17 0x42
Delete Directory 0x16 0x0B
Delete Old Auditing File 0x58 0x15
Delete Property 0x17 0x3A
Delete Trustee 0x16 0x2B
Delete Trustee From Directory 0x16 0x0E
Destroy Queue 0x17 0x65
Detach Queue Server From Queue 0x17 0x70
Disable Auditing On Volume 0x58 0x07
Disable Station Broadcasts 0x15 0x02
Disable File Server Login 0x17 0xCB
Disable Transaction Tracking 0x17 0xCF
Down File Server 0x17 0xD3
Enable Auditing On Volume 0x58 0x08
Enable Station Broadcasts 0x15 0x03
Enable File Server Login 0x17 0xCC
Enable Transaction Tracking 0x17 0xD0
End Of Job 0x18 None
Enter Login Area 0x17 0x0A
Erase Files 0x44 None
Examine Semaphore 0x20 0x01
File Close 0x42 None
File Create 0x43 None
File Open 0x4C None
File Read 0x48 None
File Release Lock 0x02 None
File Rename 0x45 None
File Search Continue 0x3F None
File Search Initialize 0x3E None
File Server Copy 0x4A None
File Set Lock 0x01 None
File Write 0x49 None
Fill Name Space Buffer 0x16 0x2F
Finish Servicing Queue Job And File 0x17 0x72
Get Account Status 0x17 0x96
Get Active Connection List By Type 0x7B 0x0E
Get Active LAN Board List 0x7B 0x14
Get Active Protocol Stacks 0x7B 0x28
Get Auditing Flags 0x58 0x13
Get Bindery Access Level 0x17 0x46
Get Bindery Object Access Level 0x17 0x48
Get Bindery Object Disk Space Left 0x17 0xE6
Get Bindery Object ID 0x17 0x35
Get Bindery Object Name 0x17 0x36
Get Broadcast Message 0x15 0x01
Get Cache Information 0x7B 0x01
Get Connection Information 0x17 0x16
Get Connection List From Object 0x17 0x1F
Get Connection's Open Files 0x17 0xDB
Get Connection's Semaphores 0x17 0xE1
Get Connection's Task Information 0x17 0xDA
Get Connection's Usage Statistics 0x17 0xE5
Get Connections Using A File 0x17 0xDC
Get CPU Information 0x7B 0x08
Get Dir Entry 0x16 0x1F
Get Dir Info 0x16 0x2D
Get Directory Base 0x57 0x16
Get Directory Cache Information 0x7B 0x0C
Get Directory Path 0x16 0x01
Get Disk Cache Statistics 0x17 0xD6
Get Disk Channel Statistics 0x17 0xD9
Get Disk Utilization 0x17 0x0E
Get DM Info 0x5A 0x01
Get Drive Mapping Table 0x17 0xD7
Get Effective Directory Rights 0x16 0x03
Get Effective Rights 0x16 0x2A
Get Encryption Key 0x17 0x17
Get Extended Volume Info 0x16 0x33
Get File Bit Map 0x55 None
Get File Server Date And Time 0x14 None
Get File Server Description Strings 0x17 0xC9
Get File Server Information 0x17 0x11
Get File Server Information 0x7B 0x02
Get File Server LAN I/O Statistics 0x17 0xE7
Get File Server Login Status 0x17 0xCD
Get File Server Misc Information 0x17 0xE8
Get File Size 0x47 None
Get File System Statistics 0x17 0xD4
Get Garbage Collection Information 0x7B 0x07
Get General Router And SAP Information 0x7B 0x32
Get Internet Address 0x17 0x13
Get IPX/SPX Information 0x7B 0x06
Get Known Networks Information 0x7B 0x35
Get Known Servers Information 0x7B 0x38
Get LAN Common Counters Information 0x7B 0x16
Get LAN Config Strings 0x7B 0x18
Get LAN Configuration Information 0x7B 0x15
Get LAN Custom Counters Information 0x7B 0x17
Get LAN Driver's Configuration Information 0x17 0xE3
Get Loaded Media Number List 0x7B 0x2F
Get Logical Record Information 0x17 0xE0
Get Logical Records By Connection 0x17 0xDF
Get LSL Information 0x7B 0x19
Get LSL Logical Board Statistics 0x7B 0x1A
Get Media Manager Object Children List 0x7B 0x20
Get Media Manager Object Information 0x7B 0x1E
Get Media Manager Object List 0x7B 0x1F
Get Media Name By Media Number 0x7B 0x2E
Get Member Set M of Group G 0x17 0x09
Get Name Space Entry 0x16 0x30
Get NetWare File Systems Information 0x7B 0x03
Get Network Router Information 0x7B 0x33
Get Network Routers Information 0x7B 0x34
Get Network Serial Number 0x17 0x12
Get NLM Information 0x7B 0x0B
Get NLM Loaded List 0x7B 0x0A
Get NLM's Resource Tag List 0x7B 0x0F
Get NS Entry Info 0x57 0x06
Get NS Info 0x57 0x17
Get NS Path 0x57 0x1C
Get Object Connection Numbers 0x17 0x15
Get Object Disk Restrictions 0x16 0x29
Get Object Effective Rights 0x16 0x32
Get OS Version Information 0x7B 0x0D
Get Packet Burst Information 0x7B 0x05
Get Path From Directory Entry 0x16 0x1A
Get Personal Message 0x15 0x05
Get Physical Disk Statistics 0x17 0xD8
Get Physical Record Locks By Connection And File0x17 0xDD
Get Physical Record Locks By File 0x17 0xDE
Get Printer Queue 0x11 0x0A
Get Printer Status 0x11 0x06
Get Protocol Stack Configuration Information 0x7B 0x29
Get Protocol Stack Custom Information 0x7B 0x2B
Get Protocol Stack Numbers By LAN Board Number 0x7B 0x2D
Get Protocol Stack Numbers By Media Number 0x7B 0x2C
Get Protocol Stack Statistics Information 0x7B 0x2A
Get Queue Job List 0x17 0x6B
Get Queue Job's File Size 0x17 0x78
Get Relation Of An Object 0x17 0x4C
Get Semaphore Information 0x17 0xE2
Get Server Information 0x7B 0x36
Get Server Set Categories 0x7B 0x3D
Get Server Set Commands Information 0x7B 0x3C
Get Spool Queue Entry 0x11 0x04
Get Station Number 0x13 None
Get Station's Logged Information 0x17 0x05
Get User Information 0x7B 0x04
Get Volume Audit Statistics 0x58 0x01
Get Volume Info With Handle 0x16 0x15
Get Volume Info with Number 0x12 None
Get Volume Information 0x17 0xE9
Get Volume Name 0x16 0x06
Get Volume Number 0x16 0x05
Get Volume Segment List 0x7B 0x21
Get Volume Switch Information 0x7B 0x09
Get Volume Usage 0x16 0x2C
Is Bindery Object In Set 0x17 0x43
Is Station A Manager 0x17 0x49
Is User Audited 0x58 0x09
Lock File Set 0x04 None
Lock Logical Record Set 0x0A None
Lock Physical Record Set 0x1B None
Log File 0x03 None
Log Logical Record 0x09 None
Log Network Message 0x17 0x0D
Log Physical Record 0x1A None
Login As Volume Auditor 0x58 0x03
Login Object 0x17 0x14
Login Object Encrypted 0x17 0x18
Login User Object 0x17 0x00
Logout 0x19 None
Logout As Volume Auditor 0x58 0x0D
Map Directory Number To Path 0x16 0xF3
Map Number To Group Name 0x17 0x08
Map Number To Object 0x17 0x04
Map Object To Number 0x17 0x03
Map User To Station Set 0x17 0x02
Modify Maximum Rights Mask 0x16 0x04
Move Entry 0x16 0x2E
Negotiate Buffer 0x21 None
Negotiate LIP Buffer 0x61 None
Open Bindery 0x17 0x45
Open Data Stream 0x16 0x31
Open Message Pipe 0x15 0x06
Open Semaphore 0x20 0x00
Packet Burst Connection 0x65 None
Purge All Erased Files 0x17 0xCE
Purge Erased Files 0x16 0x10
Purge Salvagable File 0x16 0x1D
Read Audit Config Header 0x58 0x0B
Read Auditing Bit Map 0x58 0x0A
Read Extended NS Info 0x57 0x1A
Read NS Info 0x57 0x13
Read Property Value 0x17 0x3D
Read Queue Current Status 0x17 0x66
Read Queue Job Entry 0x17 0x6C
Read Queue Server Current Status 0x17 0x76
Recover Salvagable File 0x16 0x1C
Release File 0x05 None
Release File Set 0x06 None
Release Logical Record 0x0C None
Release Logical Record Set 0x0D None
Release Physical Record 0x1C None
Release Physical Record Set 0x1D None
Remove Audit Property 0x58 0x06
Remove Entry From Spool Queue 0x11 0x05
Remove Job From Queue 0x17 0x6A
Rename Bindery Object 0x17 0x34
Rename Directory 0x16 0x0F
Reset Audit History File 0x58 0x0F
Reset Auditing File 0x58 0x0E
Restore Directory Handle 0x16 0x18
Restore Erased File 0x16 0x11
Restore Queue Server Rights 0x17 0x75
Save Directory Handle 0x16 0x17
Scan Bindery Object 0x17 0x37
Scan Bindery Object Trustee Paths 0x17 0x47
Scan Dir Entry 0x16 0x1E
Scan Dir Restrictions 0x16 0x23
Scan Directory For Trustees 0x16 0x0C
Scan Directory Information 0x16 0x02
Scan Entry For Trustees 0x16 0x26
Scan File Information 0x17 0x0F
Scan File Physical 0x16 0x28
Scan NS Entry Info 0x57 0x03
Scan Property 0x17 0x3C
Scan Salvagable Files 0x16 0x1B
Scan Volume For Restrictions 0x16 0x20
Search File 0x40 None
Send Broadcast Message 0x15 0x00
Send Console Broadcast 0x17 0xD1
Send Personal Message 0x15 0x04
Service Queue Job And Open File 0x17 0x71
Set Dir Restriction 0x16 0x24
Set Directory Handle 0x16 0x00
Set Directory Information 0x16 0x19
Set Entry 0x16 0x25
Set Extended File Attributes 0x4F None
Set File Attributes 0x46 None
Set File Information 0x17 0x10
Set File Server Date And Time 0x17 0xCA
Set File Time And Date 0x4B None
Set NS Entry DOS Info 0x57 0x07
Set Queue Current Status 0x17 0x67
Set Queue Server Current Status 0x17 0x77
Set Spool Flags 0x11 0x02
Set Trustee 0x16 0x27
Set Volume Restrictions 0x16 0x21
Signal Semaphore 0x20 0x03
Specify Capture File 0x11 0x09
Spool Data To A Capture File 0x11 0x00
Spool Existing File 0x11 0x03
Submit Account Charge 0x17 0x97
Submit Account Hold 0x17 0x98
Submit Account Note 0x17 0x99
TTS Abort Transaction 0x22 0x03
TTS Begin Transaction 0x22 0x01
TTS End Transaction 0x22 0x02
TTS Get Application Thresholds 0x22 0x05
TTS Get Control Flags 0x22 0x09
TTS Get Statistics 0x17 0xD5
TTS Get Workstation Thresholds 0x22 0x07
TTS Is Available 0x22 0x00
TTS Set Application Thresholds 0x22 0x06
TTS Set Control Flags 0x22 0x0A
TTS Set Workstation Thresholds 0x22 0x08
TTS Transaction Status 0x22 0x04
Verify Bindery Object Password 0x17 0x3F
Verify Bindery Object Password Encrypted 0x17 0x4A
Verify Network Serial Number 0x17 0x0C
Wait On Semaphore 0x20 0x02
Write Audit Config Header 0x58 0x11
Write Auditing Bit Map 0x58 0x10
Write Extended NS Info 0x57 0x1B
Write NS Info 0x57 0x19
Write Property Value 0x17 0x3E