Ever had one dump all the pointers in the mode block ?

It also cleared out the fwd station, fwd trunk,direct station and trunk ?

I had to do a default to get it all back,I did try and put them all back in by hand but it was doing some weird stuff ....

Yes, once. I had a backup of the flash and tried to use that to restore it, but it didn't work. Had to default and start from scratch. Defaulting and copying the parts back was a waste of time.

Was told by TS that "something got corrupted during the nightly maint" process. All in all, the 4E has been a pretty trouble-free VM, we've got quite a few out in the field. Just wish there was a reliable backup method (if anyone knows of one, please don't keep it a secret!).

"""Ever had one dump all the pointers in the mode block ?"""

Yes, had this happen once. I had to default and reprogram as well. At least it kept the Menu prompts.

The most reliable back up on the svmi-4e is to copy only the needed files onto your laptop. All you need to copy is in the DTA directory anything that is *.dta, copy the entire MBX folder, and copy any of the custom prompt recordings. That's it. If you want to back up messages then copy the MSG folder. When I copy this stuff back onto a svmi to restore a system I'll manualy run the maint. routine after I'm done copying and it's never been a problem. I've never seen my mode block get corrupted but I've seen other strange things happen.

I believe benb meant *.tbl files from dta directory, not *.dta
The most reliable backup I've found is to pull the flash, put it in your reader and copy the files onto your laptop directly.
Next time, try to restore the block.old back to block.tbl, seems to solve quite a few problems (no boot, etc) for me.

robe2conoby,

Yes this has happened before to me. I found that sometimes when copying the flash to the laptop,
SOMETIMES not ALL the files get copied over.
The ones that are inside of a directory.

I always check and make sure ALL files are copied.

D.

Good catch thefraz! I was a little tired this morning I did mean *.tbl. Thanks for noticing.

Same here. Had a 100 with the 4e dump everything. You are not alone on this one.

I've had 3 separate systems dump on me in the last year.

the fix: copy block.old block.tbl

quality control issue?

I guess the question here is are all the svmi-4e's in question here on the latest software release. There have been many revisions since the first one and a lot of the revisions fixed issues like the ones being described here.

Had a brand new svmi 8-e do it yesterday

No help from tech support Could not explaine how or why

At a minimum I would thing the 4111 patch on the 4e's will take care of the trouble. But also turn off download from system, it seems to be what stopped most of these problems from happening.

I'm bringing this thread back up as I've had several 4E's do this to me and I'm a little tired of it. System will be fine for months and then all of a sudden the block.tbl/bak/old files will all get hosed. Nothing to do but default and start over. I've had it happen on every revision of 4E there is. The only thing I've noticed is that it seems to always happen on the day its scheduled to reboot during maintenance, so either a monday or the 1st of the month. I'm thinking of setting this feature to no from now on. I know this feature was added before the "E" series svmi's to solve a deleted msg cleanup problem, does anyone know if its necessary anymore?

You raised a good question MichaelV. The reboot at maintenance in my opinion is not a needed setting. But to confirm it I will check with Scott H. He is the guy that designed the SVMI voicemail system. In the past I turned off the reboot at maintenance for the same reason being described here. Since the lastest revisions I have left it on and have not had any problems though. I'll make a point to check on this for you and post a reply to this thread.

Ok, emailed the engineer and got a reply. I will put a quote in directly from him. "The DOS OS in general often has trouble with memory management. In heavy traffic systems with lots of memory buffering it has been useful to periodically flush the memory by performing a reboot once a month at maintenance. There were some sites years ago (again pre E-Series) where they had to reboot weekly or even daily, but those were very rare." In my personall experience I have not run into the problems your having. I don't think after reading this reply from Scott that it's part of your problem. There a lot of factors involved that could cause corruption on a svmi. Here is another quote regarding the svmi in question MichaelV from the guy who designed it himself. "Is there any other corruption besides the Mode Block? Are there any errors on the drive? What has Samsung’s Tech Support said regarding this problem? What trouble shooting steps have already been taken? How many times is the system restarted without first running the SVMi’s proper shut down?" I'm passing this info along in hope that some of you will learn something about the svmi and the troubleshooting involved with it. I personally think it's the best VM I've ever worked with. I can do anything with it, it's very fast and configurable.

Yes, I agree with you Ben in that I think it is one of the best VM's I've ever worked with. I don't want to come across like I'm bashing it at all because I'm not. I really have ZERO issues with it except this, and it's only on the 4e's. I've also spoken with Scott H. before(not on this issue) so I know who you are talking about. We have a lot of svmi 4e's out there and this problem has come up on about 10% of them, and a few of those multiple times. To answer Scott's questions:

Any other corruption? I don't know how to tell since the system generally doesn't boot.

Errors on the drive? If he is talking about temp files, there is usually 1 or 2. If he is talking about chkdsk, nothing out of the ordinary.

Tech support has been unable to explain to me why this has happened(see first 2 questions) and so far not felt the need to replace anything.

Trouble shooting steps? Usually call from customer that VM isn't working results in the girls at the office telling them to power off/on the switch. Then if it still doesn't work I'll get sent out to find that the svmi is either continuously rebooting or boots with an invalid block table and won't answer any calls or answers with silence and/or hangup. Most of the time when I get the system to the dos prompt I'll find that the block.tbl/bak/old files are all the same size with the same date and time of creation, 3am on whatever day it happened. There is always still mbx's in the mbx folder and msg's in the msg folder. I've tried to restore msg's but it never works. I'll end up defaulting and starting over. And defaulting the system always brings it back.

How many times before a proper shutdown? Not sure what he is asking here. Every customer is different, each site different. Is he talking about random power outages before the failure? How many times the customer powered the switch off/on before I got there? How can I tell? I myself always take the VM down properly if I can commuicate with it via comm port. If not, then and only then will I hit reset button on VM.

Thanks Ben for the response! I've read many of your posts and respect your opinion on this. I've been a certified Samsung tech since the original DCS rolled out so I'm very familiar with the product. However, this issue has me stumped. I'm hoping an extra head here will help.

I also have a lot of SVMI 4e's in the field. One problem that I just encountered is that all the ports were locked. MBX dir and MSG dir wre both empty. All the messages and mailboxes were gone. I copied the entire flash to my laptop and then defaulted it. Then copied the dta, mbx, msg, and prompt dirs back onto the flash drive per tech supports recomendation Rebooted and all the ports were locked again. I then defaulted it again and copied all the directories except the dta dir and it has worked fine since.
Seems like most of the corruption I have run into in the past has been in the dta dir.

I have had a few of the original svmi 4's in high traffic locations that would not let you leave a message until the system was rebooted.