On z/OS the rmData.log should not be stored in the workarea as this is lost on a clean start

[djmatthews]

Describe the bug
On z/OS the rmData.log should not be stored in the workarea as this is lost on a clean start. Moreover, the Liberty runtime appears to automatically clean the workarea if the app server was not stopped normally (see comments in ServerLock.java). Since the rmData.log is required to successfully complete any outstanding RRS work from the previous execution of the app server, that RRS work is stranded and outstanding transaction recovery does not occur.

Steps to Reproduce
Kill a Liberty app server that is running on z/OS with RRS resources. NOTE that the RM Name reported in messages CWLIB0103I and CWLIB0104I have changed. RRS Panels show the old RM Name in Reset state and the new RM Name in Run state.

Expected behavior
The app server should use the existing RM Name on restart.

Diagnostic information:

• OpenLiberty Version: [All, 22.0.0.12]
• Affected feature(s) [zosTransaction-1.0, general transaction service]
• Java Version: [any]

Additional context
Because the rmData.log is stored in the workarea, it is lost on a --clean start.

[tjwatson]

com.ibm.ws.ssl.config.WSKeyStore.locationInOutputDir(String) is an example of finding the output area for ${server.output.dir}/resources/security/