Endevor CONMOVE utility failing to copy members with message CIMV001I showing a nonzero RC

Products

• Endevor

Issue/Introduction

Processor utility CONMOVE may fail to copy the processor outputs between the specified FROM and TO datasets with an error message like:

14:38:22  C1MV001I  BSTCOPY CALLED TO COPY MEMBER(S) TO <output.dataset>  RC=0012                          
14:38:23  C1X0010I  STEP COPY PROGRAM CONMOVE COMPLETED, RC=0012                                                        
14:38:23  C1G0129E  STEP COPY RC (0012) EXCEEDS THE MAX RC (0004) FOR THE PROCESSOR STEP

This message causes the MOVE processor and consequently the MOVE action to fail

Cause

CONMOVE utility reads the component list of the element being moved. For each output library recorded in the component list which matches the dataset name pattern specified in a FROM clause in the CONMVIN DD statements, it tries to copy the output members that show up in the component list for that library to the corresponding library specified in the TO clause.

To do that, the utility does as follows for each library to be copied:

• Dynamically allocates the input and output libraries
• Builds COPY statements to be processed by BSTCOPY
• Invokes BSTCOPY under the covers to perform the copy

If BSTCOPY issues a nonzero RC, CONMOVE fails with the above messages.   

Resolution

If BSTCOPY issued a nonzero RC, it should have printed error messages to SYSPRINT DD. This ddname is normally allocated by the processor step that calls CONMOVE. If SYSPRINT DD is not allocated by the processor, then CONMOVE dynamically allocates it as //SYSPRINT DD SYSOUT=*

Your first step is therefore to look for SYSPRINT DD among the JES2 outputs from the job step that executed the MOVE action. You can use the output dataset name written in message C1MV001I to identify the COPY operation that fails. For example:

14:38:22  C1X0511I  COPY COMMAND # 1                                                                    
14:38:22  C1X0511I  INDD1   = <input.dataset>                                            
14:38:22  C1X0511I  OUTDD01 = <output.dataset>

If there is no SYSPRINT DD in the JES2 output for the step, then you need to check the processor to see how it manages SYSPRINT DD. Chances are that it stores the output in a listing library where you can browse it to see what is the problem.

If the processor does not keep SYSPRINT DD anywhere, then the messages from BSTCOPY are lost. In this case, you need to adjust the processor so that it stores SYSPRINT DD or allows it to go to SYSOUT=* and repeat the MOVE action to see what is the problem found by BSTCOPY.