I’m looking for advice on how to address the following problem.
I have a procedure that was given to me by a previous employee (that apparently used to work well). The procedure is copying a dialog from one CV to another (Production to Test in this case).
The procedure, of course, starts with extracting the Dialog and associated maps, records, elements from production. These are put into files that are, in turn, used in an ‘upload’ job which deletes the dialog and associated maps, records, elements from test and then adds the dialog, etc to the test CV.
I have run into a DC601046 error attempting to delete a record from the target (test) system – See the attached screenshot. After this error I get other errors – DC601006 – which I initially assumed were because of the first Record issue, but after looking closer it appears that the elements it is trying to delete are not related to the record in any way.
This thread looked promising so I tried it. https://communities.ca.com/thread/100655843 (I didn’t have SQL access enabled but it was easy to enable.)
After SETting BUILDER_036='D' (it was ‘C’) I tried to run my ‘upload’ job from the top. This produced a more significant problem – an S000 U3134 abend - at the point of the 'delete Skeleton-map-record' statement. with Message DC601900 and Error Code 0069 showing in the sysout on the DDDLDEL step. Not sure what 0069 means (0069 is major code = 00 and minor code = 69). The job had more informative messages: DC410003 and DC410006. The first indicates "DNS SEND/RECEIVE Failure Status is : 5839" and the 5839 (major 58 and minor 39) indicates "SVC SEND/RECEIVE This front-end has lost contact with the back-end CV. Check the back-end system's DC log for more information." The DC410006 indicates "DNS Processing error, Function is RECEIVE_AND_WAIT, Status is XMIT Error DTS: Abend on path's subsequent downstream node DTS: Logical connections to node disabled DTS: Physical connection to node disabled"
So I tried switching back to BUILDER_036='C'. This got me back to where I was before -- I think. Maybe I need to delete the skeleton-map-record manually. (The elements within are independently created so won't impact them. And the process does try to recreate skeleton-map-record with the same elements. It is "copied into" hundreds of maps and programs.) But I think deleting the skeleton-map-record will only fix that one error and I have 94 others – most of which are DC601006 on deletion of elements.
I would say that the entities involved are very widely used and you will never successfully delete them. For example - AGR-MAP-RSPONSE - likely used on every map in the system! So my suggestion would be - don't delete them - and ignore the errors on the add!
My bet would be that everything else will work fine. If you want non-zero return codes - then edit the files (set up an edit macro and put it into the job stream) before running them through the compilers to remove (or comment out) the known entities that are the regular offenders!
HTH - cheers - Gary
First check if there are changes to the record you have issues with, if not, there is no need to migrate it.If it was changed and you definitely need to move it, you can use this process.
1. Change the version in the target dictionary to 2, or a version that does not exist.
2. Migrate the map, the delete will fail as the record no longer exists, but you can add the new version 1 record.
After successfully migrating the map and creating the new record, you should update and compile all the other maps which are still attached to the old record that now has a different version, and change the version back to 1 within MAPC, MAPC will retain the field assignments where possible, after that, you will need to recompile all dialogs that call those updated maps, and possibly also programs.
Because the extraction program runs in another environment, different from the destination, there may be more dialogs or maps associated with these records.You should check the relationships in the target, not only at the origin.All dialogs and maps should be deleted by the utilities IDMS .