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

book

Article ID: 132126

calendar_today

Updated On:

Products

CA 2E

Issue/Introduction



We are planning to upgrade CA 2E from 8.6 to 8.7.
YTRGRCVP has no reference in the 8.7 documentation, so 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. However it seems it is not in our customer environments. Can you please confirm if YTRGRCVP should be part of the runtime and if yes what is the impact of it not being on customer environment running triggers?

Environment

Release: K1EBAS04400-8.7-2E-400 Toolkit
Component:

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. Now both of these objects YTRGRCVP and YTRGDBG are created by the YDUPAPPOBJ command in the run time library designated by the user. 

NOTE: At r8.6 these objects were not created by default by the YDUPAPPOBJ command in the run time library. They had to be added back in later. But this has been resolved in r8.7. After upgrading model to r8.7, when doing a YDUPAPPOBJ again, these objects would be created correctly in the run-time 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 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 again. 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. 

So 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.