CISCO-CONFIG-COPY-MIB question

Answered Question
Jan 6th, 2010

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)?

I have this problem too.
0 votes
Correct Answer by Joe Clarke about 6 years 11 months ago

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.

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (1 ratings)
Loading.
Joe Clarke Wed, 01/06/2010 - 09:09

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.

yjdabear Wed, 01/06/2010 - 09:22

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?

Correct Answer
Joe Clarke Wed, 01/06/2010 - 09:25

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.

Actions

This Discussion