diff --git a/TODO.md b/TODO.md
index b88dac7..c442354 100644
--- a/TODO.md
+++ b/TODO.md
@@ -106,6 +106,16 @@ Current status:
 - `NCP 0x03 Log File (old)` is implemented, but still belongs on the audit
   list because the original source already marked this old log/lock area as
   not well tested.
+- `NCP 0x04 Lock File Set (old)` and `NCP 0x6a Lock File Set` share the
+  current implementation.  The SDK documents the old `0x04` timeout word as
+  Lo-Hi and the newer `0x6a` timeout word as Hi-Lo; MARS-NWE currently reads
+  the shared field with `GET_BE16()`.  This is documented inline but not
+  changed yet.
+- `NCP 0x05 Release File (old)` and `NCP 0x07 Clear File (old)` have request
+  parsing that matches the documented old header offsets.
+- `NCP 0x06 Release File Set` and `NCP 0x08 Clear File Set` are implemented,
+  but the SDK request contains a `LockFlag` byte that the current code does
+  not read.  This parser difference is documented inline but not changed yet.
 
 Follow-up:
 
@@ -114,6 +124,11 @@ Follow-up:
   completion with normalized endpoint logging.
 - Verify `NCP 0x03 Log File (old)` against the Novell SDK request/reply layout
   and a real DOS requester or direct test caller.
+- Decide whether the shared `0x04`/`0x6a` parser should keep the current
+  big-endian timeout read for both functions or special-case old `0x04` as
+  documented Lo-Hi after direct requester evidence is available.
+- Decide whether `0x06` and `0x08` should consume or ignore the documented
+  `LockFlag` byte after direct requester evidence is available.
 - Verify the implemented file/logical-record/physical-record calls against the
   Novell SDK request/reply layouts and a real DOS requester or direct test
   caller.
diff --git a/src/nwconn.c b/src/nwconn.c
index 3215310..188837a 100644
--- a/src/nwconn.c
+++ b/src/nwconn.c
@@ -2833,15 +2833,26 @@ static int handle_ncp_serv(void)
          * File Set lock all files logged by the calling client's current
          * task.
          *
-         * SDK request: 2-byte Lock Timeout, in units of 1/18 second;
-         * 0 means No Wait.
-         * SDK reply: no reply data.
-         * SDK completion: 0x00 success, 0xfe timeout, 0xff lock error.
+         * SDK request:
          *
-         * The newer 0x6a call replaces the old 0x04 call but has the same
-         * request layout for the file set lock itself.  MARS-NWE records
-         * file-set members through Log File (0x03), then uses the shared
-         * set handler for Lock/Release/Clear File Set operations.
+         *   0x04 old: word LockTimeout, documented as Lo-Hi.
+         *   0x6a new: word LockTimeout, documented as Hi-Lo.
+         *
+         * SDK reply: no reply data.
+         * SDK completion: 0x00 success; old 0x04 documents 0xfe timeout
+         * and 0xff lock error, while newer 0x6a also documents
+         * 0x7f ERR_LOCK_WAITING.
+         *
+         * The newer 0x6a call replaces the old 0x04 call for NetWare 3.x
+         * and later.  MARS-NWE currently handles both calls in one branch
+         * and reads the timeout with GET_BE16().  That matches the 0x6a
+         * Hi-Lo SDK layout; the old 0x04 SDK page documents Lo-Hi.  This
+         * comment records the wire-layout difference only; the parser is
+         * intentionally left unchanged in this documentation pass.
+         *
+         * MARS-NWE records file-set members through Log File (0x03), then
+         * uses the shared set handler for Lock/Release/Clear File Set
+         * operations.
          */
         struct INPUT {
           uint8   header[7];       /* Requestheader */
@@ -2857,6 +2868,29 @@ static int handle_ncp_serv(void)
       
       case 0x5 :    /* Release File  */
       case 0x7 : {  /* Clear File, removes file from logset */
+        /*
+         * NCP 0x2222/05 Release File (old) releases one previously
+         * locked file but leaves it in the client's logged file table.
+         * NCP 0x2222/07 Clear File (old) removes one file from that
+         * table; if it is locked/open, the server releases/closes it.
+         *
+         * SDK request for both calls:
+         *
+         *   byte  DirectoryHandle
+         *   byte  FileNameLen
+         *   bytes FileName
+         *
+         * SDK reply: no reply data.
+         * SDK completion for 0x05: 0x00 success, 0x9c invalid path,
+         * 0xff unlock error.
+         * SDK completion for 0x07 additionally documents 0x96 server out
+         * of memory, 0x98 disk map error, 0x9b bad directory handle,
+         * 0xa1 directory I/O error, and 0xfd bad station number.
+         *
+         * The current INPUT layout matches the documented old request
+         * header offsets: FunctionCode at offset 6, DirectoryHandle at
+         * offset 7, FileNameLen at offset 8, and FileName at offset 9.
+         */
         struct INPUT {
           uint8   header[7];       /* Requestheader */
           uint8   dir_handle;
@@ -2876,6 +2910,25 @@ static int handle_ncp_serv(void)
 
       case 0x6 :    /* Release File Set */
       case 0x8 :  { /* Clear File Set  */
+        /*
+         * NCP 0x2222/06 Release File Set releases all currently logged
+         * or locked files, but keeps the file-log table entries.
+         * NCP 0x2222/08 Clear File Set releases/removes all logged files;
+         * open server-side file handles are invalidated by the NetWare
+         * semantics described in the SDK.
+         *
+         * SDK request for both calls:
+         *
+         *   byte  LockFlag
+         *
+         * SDK reply: no reply data.
+         * SDK completion: 0x00 success.
+         *
+         * MARS-NWE currently does not read the documented LockFlag byte
+         * and forwards the operation directly to share_handle_lock_sets().
+         * This documentation patch records that parser difference only;
+         * endpoint behaviour is intentionally unchanged here.
+         */
         int result = share_handle_lock_sets(
                                       1,   /* File Set */
                                (function==0x8)