There are a bunch of blocking related options that let you control blocking behaviour that can be set at a connection level either for the duration of the connection or temporarily.
http://dcx.sybase.com/index.html#sa160/en/dbadmin/blocking-others-timeout-database-option.html
http://dcx.sybase.com/index.html#sa160/en/dbadmin/blocking-timeout-option.html
http://dcx.sybase.com/index.html#sa160/en/dbadmin/blocking-option.html
Using the different interfaces causes slightly different behaviour under the covers as to when an actual row is fetched and the block occurs. In the JConnect vs iAnywhere JDBC case, the JConnect executeQuery executes and opens the cursor to begin fetching, causing the block to occur, but iAnywhere driver does not do this work until you actually execute the fetch (ie. resultset.next).
The stored procedure behaviour is a little odd, but I suspect some execution of the select statement has to occur in order to determine if there is actually a result set that must be returned to the client.