+.SS Sequence File Format
+The sequence file format is based on the RFC\-5322 message format. Each line
+of the sequence file corresponds to one sequence. The line starts with the
+sequence name followed by a `:', then followed by a space-separated list of message numbers
+that correspond to messages that are part of the named sequence. A contiguous
+range of messages can be represented as \*(lqlownum\-highnum\*(rq.
+.PP
+.B Sample sequence file
+.PP
+.RS 5
+.nf
+work: 3 6 8 22-33 46
+unseen: 47 49-51 54
+cur: 46
+.fi
+.RE
+.PP
+.B Nmh
+commands that modify the sequence file will silently remove sequences for
+nonexistant messages when the sequence file is updated. The exception to
+this is the \*(lqcur\*(rq sequence, which is allowed to point to a
+nonexistant message.
+.SS Sequence File Locking
+The \*(lqdatalocking\*(rq profile entry controls the type of locking used
+when reading and writing sequence files. The locking mechanisms supported
+are detailed in
+.IR mh\-profile (5).
+This protects sequence file integrity when multiple
+.B nmh
+commands are run simultaneously.
+.B Nmh
+commands that modify the sequence file use transactional locks; the lock
+is held from the time the sequence file is read until it it written out.
+This ensures that modifications to the sequence file will not be lost
+if multiple commands are run simultaneously. Long\-running
+.B nmh
+commands, such as
+.B inc
+and
+.BR pick ,
+will release the sequence lock during the bulk of their runtime and reread
+the sequence file after their processing is complete to reduce lock
+contention time.
+.PP
+.B Note:
+Currently transactional locks are
+.B only
+supported for public sequences; private sequences will not get corrupted, but
+the possibility exists that two
+.B nmh
+commands run simultaneously that add messages to a private sequence could result in
+one command's messages not appearing on the requested sequence.