I have call accounting data coming in on tty1a12. My call accounting software reads this just fine. But now I am writing new software that also needs to read this data. The call accounting software is in DB/C and is from a vendor. Mine is in C.
Initially I was just going to do
cat /dev/tty1a12 >> /u/maid/smdr&
And then write a script to run in cron and make sure this was always going. I suppose a -NOHUP would help, but I have had trouble out of this and generally, I don't find it trustworthy.
But the problem is that this does not seem to work anymore. When I first tested my software I used the above line and got some sample data which I used to test with. Now that I am ready to put this out live, when I use the above line, I get incomplete data. It's as though it gets only 1/2 the data line. The call accounting is still getting complete data records though.
So what would you guys suggest to read this data stream in a non-blocking fashion? Is there a more reliable and graceful way to "dup" this stream? What is generally coming out is a 110 byte call record, at random intervals. But you cannot count on it being exactly 110 bytes.
Thanks,
Tim
Initially I was just going to do
cat /dev/tty1a12 >> /u/maid/smdr&
And then write a script to run in cron and make sure this was always going. I suppose a -NOHUP would help, but I have had trouble out of this and generally, I don't find it trustworthy.
But the problem is that this does not seem to work anymore. When I first tested my software I used the above line and got some sample data which I used to test with. Now that I am ready to put this out live, when I use the above line, I get incomplete data. It's as though it gets only 1/2 the data line. The call accounting is still getting complete data records though.
So what would you guys suggest to read this data stream in a non-blocking fashion? Is there a more reliable and graceful way to "dup" this stream? What is generally coming out is a 110 byte call record, at random intervals. But you cannot count on it being exactly 110 bytes.
Thanks,
Tim