ECHI producing zero bit files and not transferring

[Starr Stealer]

System Environment Details:
CMS v13.1 installed on the Sun Netra 210
ECHI Converter 3rd party install on Ubuntu 9.04
http://echi-converter.rubyforge.org/

We are working to meet a few client needs to provide full reports
containing call details. We have found in our system there are two
locations for this type of data. One is inside the Informix database
in the call_rec table, the other on the 8700’s in a flat file called
the CDR. I can tell these two data set’s are for two different
purposes, and that the call_rec table fits the bill for our client
needs.

We recently have found out the limits of the call_rec storage. Prior
to this discovery, we had already built a data repository that CMS was
exported into on regular intervals per table sets. We are starting to
see discrepancies in our data sets, compared to total volume reported
from vdn tables. Even the CDR records are slightly off in row counts,
which all seem to be abandon calls. It is looking like our call volume
is too large to manage the export of call_rec, so we found out about
the ECHI feature in CMS.

We set up the 3rd party ECHI Converter and wrote custom copy scripts
using SCP. The chr## files should automatically be transferred from
CMS to the converter server’s database. When we installed the ECHI
package on CMS, it asked if the current buffer should be exported now.
We chose yes to the prompt and the ECHI Converter received its first
file, which was tagged as a zero bit error. We continued to monitor
both servers directly and the first thing we noticed was the files on
CMS in the /cms/cmstables directory were not growing in size. Then we
notice that ECHI was not sending out a second file. We had waited
slightly over 6 hours for more files and never received another, nor
did the file size change. We disabled the ECHI converter and enabled
call_rec again.

Has anyone encountered a similar issue with the ECHI files on CMS not
sending out or growing in size. In our custom SCP copy script, we have
logging and we can tell CMS wasn’t calling the script and hitting an
error. The script was able to transfer the first file.

[incognito]

Howdy...

What sort of troubleshooting have you done?

Permissions on the UNIX file system for writing the CHR files before
transfer?
Permissions for /cms/cmstables?
File permissions for the script? +x?
Disk space?
SCP connecting fine?
Path correct on receiving end?
Permissions correct on receiving end?

Those are some of the things I'd be looking at, the other would be the
script itself.. if all fails on the above, we can look at the script
itself.

- Ryan