Taken from Strategy Analysis
During every strategy analysis, CA RC/Migrator™ for DB2 for z/OS checks for DB2 features that are not currently supported. If the product detects an attempt to operate on objects that exploit unsupported features, warning messages are directed to an output data set named RCMTOLR. If you do not want to use RCMTOLR, you can disable RCMTOLR data set creation by customizing the MIGRATOR parmlib member in hlq.CDBAPARM. However, we strongly recommend using RCMTOLR and checking for warning messages generated by the analysis before executing the strategy.
When RC/Migrator performs an analysis the RCMTOLR DD is produced by all releases. It is dynamically allocated with this format:
I want to avoid the creation of this dataset using a userid as a HLQ.
Security violations often happen when the user doing the analysis does not have authority to create such a dataset.
How can this be avoided?
DB2 for Z/OS
The purpose of RCMTOLR is documented in the RC/Migrator user Guide in the section titled 'Strategy Analysis'.
Here are three different methods to avoid this situation. The choice of these would depend on whether the user actually wants to see the messages sent to this DD or not. Normally the dynamically allocated dataset is not available for viewing after completion of the job.
These options may cause an impact on CPU time usage so that is also a choice.
- The use of the KEYWORD "HLVLPFIX" in CDBAPARM(MIGRATOR) or (RCMIGxx) as HLVLPFIX (XXXXXXXX) [up to 8 valid characters] will replace %USERID when dynamically allocating the dataset. This replacement id would have to have the authority to create the dataset.
- Add this JCL to the analysis JCL to direct all the output to sysout.
There may be a large number of messages in RCMTOLR so having it produced in sysout may increase the amount of output on the system held output queue.
//RCMTOLR DD SYSOUT=*
- Add this JCL to the analysis JCL to send all the output to a system defined temporary dataset which is then deleted if not required.
The benefit is that the dataset name does not cause trouble with the security system as it's system generated and no changes are required elsewhere. The dataset name could also be changed from &&RCMTOLR to a defined name but if there are multiple executions these may contend with each other. The system generated one is always unique to the current job.
//RCMTOLR DD DSN=&&RCMTOLR,DISP=(NEW,DELETE,DELETE),
Anecdotal information suggests that option (2) is the slowest method in terms of CPU usage so local site tests are recommended.
Depending on the security system in place various errors might be seen as symptoms of this problem.
With ACF2 : ACF99913 ACF2 VIOLATION-04,05,userid,,master catalog dataset,N/A
With RACF : ICH408I USER(userid ) GROUP(group) NAME(
master catalog dataset CL(DATASET ) VOL(volume)
INSUFFICIENT ACCESS AUTHORITY
FROM MVSCAT.* (G)
ACCESS INTENT(UPDATE ) ACCESS ALLOWED(READ)