Automatic journal feature for datasets, terminals in TXSeries for Multiplatform

RFE: Please add automatic journal feature for datasets, terminals in TXSeries for Multiplatform.

CICS TS for z/OS includes a function or feature to perform automatic journaling (https://www.ibm.com/support/knowledgecenter/SSGMCP_5.3.0/com.ibm.cics.ts.recrestart.doc/topics/dfht246.html?lang=en). On CICS TS for z/OS a hand full of properties in the FCT entry qualified a VSAM dataset for automatic journaling. This meant a CICS management program journaled changes to a given dataset to a specified user journal.
A user could later use the journaled records for recovery, statistics, audit trail or for whatever purpose they so desire.

We have a native CICS TS for z/OS application that was migrated to TXSeries for Multiplatform. The associated datasets are VSAM, KSDS, ESDS and RRDS most with embedded binary data. Structured File System (SFS) shipped with TXSeries was the natural choice to emulate VSAM.
However, on this new platform, there exist some challenges with SFS. Unlike the VSAM utilities available on a z/OS server, datasets exported outside SFS using the sfsadmin export command are not editable. The alternate cicssdt stof/ftos utilities do not lend themselves well to exporting VSAM datasets with embedded binary fields.

This presents challenges when attempting to recover one or more SFS datasets. In one example that followed the migration to TXSeiries, I run into a handful of situations where a user more than double posted payments on a user accounting process. The effort to back out the entries that were double posted has proved challenging, particularly if the recovery effort is one or more business days beyond the incident.

Perhaps if the CICS automatic journaling feature/function embedded in CICS TS were added to TXSeries environment. The sfsadmin command along with user journals would add value to the recovery process. The sfsadmin export/import feature would suffice as a backup and restore for each individual datasets, along with the use of “end-of day” user journals captured and archived through the service life of the CICS region.

Recovery would be simplified. It would entail restoring the point in time archived dateset(s) captured using sfsadmin export. Delete, define and import the SFS dataset using sfsadmin destroy/import. Along with the corresponding archived end of day journal dataset, one would be in a position to forward recover to a point just prior to the user double posting incident or failure.

Perhaps also the ability to process the archived journal dataset in batch would add value to audit and statistic reporting.

Thank you
Charles Miyawa