Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

Blue

CISCO-CONFIG-COPY-MIB question

As a result of network interruption during script execution, some of the remote devices never received the ccCopyEntryRowStatus "destroy", so I assume that field remains set to createAnd*. Would there be any danger leaving that "as is", especially considering the next execution will again attempt to set it to createAnd*? On the flip side, what happens if ccCopyEntryRowStatus receives "destroy" when it's not set (or would that be the "notInService(2)" state)?

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: CISCO-CONFIG-COPY-MIB question

Yes, you can, and I do in all of my scripts.

No, that won't work.  If a row is in a createAndWait state, it must be set to active, not createAndGo.

3 REPLIES
Cisco Employee

Re: CISCO-CONFIG-COPY-MIB question

There is no danger.  Assuming your next run of the script will do a destroy before trying to reset row objects, you will be fine.  Of course, if you're worried about it, you can always send a destory after the fact, and clean things up now.

Blue

Re: CISCO-CONFIG-COPY-MIB question

Is it to say I could summarily issue a blind "destroy" upfront regardless, as a "best practice"?

To restate my original question: Is there any [adverse] impact if ccCopyEntryRowStatus that's left in "createAndWait" state receives another "createAndWait" directive immediately after?

Cisco Employee

Re: CISCO-CONFIG-COPY-MIB question

Yes, you can, and I do in all of my scripts.

No, that won't work.  If a row is in a createAndWait state, it must be set to active, not createAndGo.

240
Views
0
Helpful
3
Replies