Reality check:

If User #1 sets pessimistic record locking on a table and
does an APPEND BLANK, the table header gets locked. This prevents others from doing an APPEND BLANK until User #1
does a TABLEREVERT()/TABLEUPDATE(), which is clearly unacceptable in a multiuser situation.

However, if User #1 sets optimistic record locking on a table and then does an APPEND BLANK followed by an RLOCK(), other users *can* successfully do their own APPEND BLANKS.

So it would it seem that the only real way to implement a
pessimistic row locking strategy using record buffering is
to use *optimistic* buffering in conjunction with explicit
locking via RLOCK().

Is my conclusion correct? This approach on the face of it
seems to be fairly subtle and not something that most developers would be likely to stumble on without a good deal of thrashing around.