CatOS 7.1(x) code - failed TFTP config push issues

Question

All,
  I have found that CatOS 7.1(1) & 7.1(2) running on multiple platforms (tested on WS-C4006 and WS-C6509 so far) does not properly work when trying to push a configuration change up to the device from a TFTP server.  Our scripts (and I also executed each snmpset manually from the CLI to make sure it wasn't a script issue) can successfully push and pull configs on other CatOS versions on both 4000 and 6000 devices but so far has failed on every attempt for 7.1(1) & 7.1(2) code on multiple platforms.  I can't find anything on CCO or the internet where someone has run into this before.
Anyone seen anything similar?
  We do large scales changes on many networks during maintainence windows and not having these devices work via SNMP and forcing us to use the CLI is a big time factor that is hindering our productivity.  Would like to know why these fail and if there is a workaround/solution?  Or do they not support SNMP/TFTP config change methods for whatever reason?
  When pushing a config change up to one of these devcie usign the 7.1.x code the status MIB will report back a 2 which means it was successful.  But the change never shows up in the config.  I'm simply trying to change the system contact in the config during my proof of concept until I found out what this issue is.
Thanks in advance for any and all help/sugeestions,
Steve 

Answer 1

Joe,
  First off thanks for any and all help that you can provide.  Here are the OIDs that I hit to push a cfg from the TFTP server to the remote CatOS switch.  I am successful in pushing changes to a 6509 running 6.5 code and 7.6(8) code but have failed to push to multiple models of CatOS devices running 7.1(1) or 7.1(2) code to date.  I can pull the cfg from these 7.1(x) boxes without a problem.  But for test purposes we have tried jsut simply changing the system contact to see if this works or not and like I said so far its has not yeilded any successful results for 7.1(x) code.
snmpwalk -c .1.3.6.1.4.1.9.5.1.3.1.1.17      <<<< se what slot the SUP module is located first
snmpwalk -c .1.3.6.1.4.1.9.5.1.5
snmpset -c .1.3.6.1.4.1.9.5.1.5.1.0 string
snmpset -c .1.3.6.1.4.1.9.5.1.5.2.0 string textfile.txt
snmpset -c .1.3.6.1.4.1.9.5.1.5.3.0 i 1
snmpset -c .1.3.6.1.4.1.9.5.1.5.4.0 i 2
snmpwalk -c .1.3.6.1.4.1.9.5.1.5.5
When we originally discovered this it was run through a script.  but through testing out using the manaual process via CLI even manaually running the snmpsets and walks fail also.
Thanks in advance,
Steve