Better error handling with record locking done in a procedure

Using procedures is far more beneficial than subroutines.  There is a catch though that record locks are not handled well in procedures.

Example 1 (works great):

Record level logic in subroutine, or in mainline.  When doing file/record level access (i.e. chain/read) and a record lock is encountered, a message is thrown with an option to [R]etry the action.  This often works/helps when the if the lock is no longer present.

Example 2 (not ideal, purpose of RFE):

Record level logic in procedure, or a linear main program.  When doing file/record level access (i.e. chain/read) and a record lock is encountered, the system automatically takes [C]ancel actions preventing an option to retry.  An inquiry message is thrown and there is no option to retry the failed action due to the lock condition (only options for C G D F).  This is not great and is more difficult to resolve.  There are ways to wrap the chain/read with (e) to trap/handle/retry the lock, but the amount of code to do this makes it a bulky solution.  IBM has confirmed this is the intended flow as the article/snippet below show.

https://www.ibm.com/docs/en/i/7.6.0?topic=gfc-record-locking

Note: Subprocedures do not get inquiry message, and so this situation should be handled by using an error indicator on the read operation and checking for status 1218 following the read.

Suggestion: 

Improve record lock handling when done in a procedure.  I realize this will not be able to be a default/global setting if IBM agrees to do this, but possible options are to enable this new behavior via a system value, jobs setting, job description attribute, etc.

Thank you for the consideration.