SELECT ... FOR UPDATE does not apply any row-level locking explicitely. It rather means that you want to update the result sets of the SELECT statement. WITH RR, on the other hand, will tell DB2 this statement will use RR isolation level to control concurrent access to the target table.
During the SELECT phase, DB2 will use S (share) row locks to prevent UPDATE, phantom insert, etc. During SELECT phase, the other sessions (concurrent activation groups) can read your table.
Only when you get to the UPDATE, will DB2 escalate the S row
lock to X (exclusive) row lock. During UPDATE, the other sessions (concurrent activation groups) cannot read your table.
So, is there a JDBC-compliant command you can use to force a row-level lock? No. Sorry to disappoint you.
DB2 will enforce the approriate level of locking. Keep in mind, DB2 tries to maximise the concurrent data access as much as possible.
To lock the entire table in question, you can use the LOCK TABLE <table name> EXCLUSIVE MODE ALLOW READ. Refer to DB2 UDB for AS/400 SQL Reference for details.
I always hesitate to answer DB2/400 questions, because even though I used it years ago, it is a different animal than the other DB2's. I don't really know how much it has changed since I last used it.
But in DB2 UDB (which now includes 390, Linux, Unix, and Windows) the statement "'select ... for update ...” (used in a cursor) causes DB2 to issue an SIX lock. An SIX lock is "Share With Intent To Update." This allows other Share locks, but no other SIX locks (and no other X locks). When the “update where current of cursor” takes place, then the X lock is issued. This should be committed as soon as possible to facilitate concurrency with other processes.