starr0stealer
IS-IT--Management
System Environment Details:
CMS v13.1 installed on the Sun Netra 210
ECHI Converter 3rd party install on Ubuntu 9.04
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.
CMS v13.1 installed on the Sun Netra 210
ECHI Converter 3rd party install on Ubuntu 9.04
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.