What is the role of 2E runtime file YTRGRCVP in trigger processing

Products

• CA 2E

Issue/Introduction

We are planning to upgrade CA 2E from 8.6 to 8.7.

YTRGRCVP has no reference in the CA 2E 8.7 documentation.  What is its role and how does it impact existing trigger processing? 

Assuming YTRGRCVP is for the processing of triggers, then we would expect YTRGRCVP to be part of the runtime.

Please confirm if YTRGRCVP should be part of the runtime and if yes what is the impact of it not being present?

Environment

CA 2E 8.7

Resolution

YTRGRCVP is a file which is used only when it is required to "debug" triggers (i.e track which file is being processed, the trigger event, timestamp, corresponding job, data being written etc).

Trigger debug control in CA 2E is controlled by the YTRGDBG data area.

Both of these objects, YTRGRCVP and YTRGDBG, are created by the YDUPAPPOBJ command in the runtime library designated by the user. 

NOTE: In CA 2E 8.6, these objects were not created by default by the YDUPAPPOBJ command in the runtime library and had to be added back in later. This has been resolved in CA 2E 8.7. After upgrading model to CA 2E 8.7, when doing a YDUPAPPOBJ again, these objects would be created correctly in the runtime library. 

Coming to the functionality, data is written into the file YTRGRCVP when the YTRGDBG (data area related to trigger debug control) data area is set to *YES. When this data area is set to *YES, then the information from the YTRGCTLP for the corresponding trigger being executed AND the job information AND the old and new data are written out to the YTRGRCVP file. 

Coming to whether it needs to be part of runtime and impact if it does not exist there, it is only used for debug and that is predominantly at development time itself. This file only works in conjunction with the YTRGDBG data area.

If the data area exists and is set to *NO and the file does not exist - no problem.

If the data area exists and is set to *YES and the file does NOT exist - no problem. The trigger processing still goes through fine and it is only that the debug data is not written to the file because it does not exist. 

In summary, there is no need to be concerned about this file not being present in the runtime, unless it is required to look at the "debug" data for trigger processing.