cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
652
Views
0
Helpful
3
Replies

CISCO-CONFIG-COPY-MIB question

yjdabear
VIP Alumni
VIP Alumni

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

Joe Clarke
Cisco Employee
Cisco Employee

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.

View solution in original post

3 Replies 3

Joe Clarke
Cisco Employee
Cisco Employee

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.

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?

Joe Clarke
Cisco Employee
Cisco Employee

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.