home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / biz / sco / general / 4906 < prev    next >
Encoding:
Internet Message Format  |  1992-12-31  |  3.9 KB

  1. Path: sparky!uunet!shady!kevin
  2. From: kevin@shady.UUCP (Kevin Smith)
  3. Newsgroups: biz.sco.general
  4. Subject: Re: Capturing data from a RS232 Port
  5. Message-ID: <73@shady.UUCP>
  6. Date: 31 Dec 92 19:00:15 GMT
  7. References: <9212302347.aa18271@alvarez.alvarez.COM>
  8. Organization: ShadeTree Software, Inc.
  9. Lines: 99
  10.  
  11. In article <9212302347.aa18271@alvarez.alvarez.COM> alexl@alvarez.COM (/dev/null) writes:
  12. >.>   From: Steven E Frazier <eng.norstan.com!sfrazier@uunet.UU.NET>
  13. >.>   Subject: Capturing data from a RS232 Port
  14. >.>   Organization: Norstan Communications - Columbus, Ohio
  15. >.>   Date: Wed, 30 Dec 1992 21:04:44 GMT
  16. >.>   Message-Id: <C03Bvy.3JB@norstan.com>
  17. >
  18. >
  19. >.>   Is there a way to use an existing program on SCO to open a file and capture
  20. >.>   data coming from say a RS232 port /dev/ttyak and then use cron to drop 
  21. >.>   DTR @ say 0200 then open the port back up?  I am thinking cu could do
  22. >.>   that but can than be run in the background?
  23. >
  24. >.>   The purpose is to capture CDR (Call Detail Records) from a PBX, at 0200
  25. >.>   close the port copy them to another file and then reopen the port again
  26. >.>   for data capture.  
  27. >
  28. >.>   Thanks in advance.
  29. >
  30. >
  31. >It is crude but it should work.
  32.  
  33. ... crude shell script ...
  34.  
  35. >
  36.  
  37. Assuming the data is some kind of newline/return terminated ASCII data,
  38. you could read it line by line.  I'll explain why in a minute.
  39.  
  40. Script to read lines from the tty and log to a file.
  41.  
  42.     LOGFILE=...
  43.     TTY=...
  44.     (
  45.     # Note: redirected input of the parenthesized(?) code
  46.     # will setup the stdin for both the stty and the read.
  47.     # You may need to fool with settings like 'ixoff, icanon,
  48.     # icrnl...' to get the right behavior.
  49.     stty .....
  50.  
  51.     # Read lines from tty one at a time and append them to the
  52.     # log file.  The logic here is that another process will
  53.     # come along and move the log file occasionally (once a day
  54.     # at... say 2am).  This methodolgy will automatically start
  55.     # new file with out skipping a beat.
  56.     while :
  57.     do
  58.         read line
  59.         echo "$line" >>$LOGFILE
  60.     done
  61.  
  62.     # Note: If the input data is non-ascii but fixed length you
  63.     # could use dd instead of the read/echo combo.  Remember to
  64.     # set -icanon on the port.
  65.     #   while :
  66.     #   do
  67.     #       dd bs=?? count=1 >>$LOGFILE
  68.     #   done
  69.     ) <$TTY
  70.  
  71. From cron, periodically
  72.  
  73.     LOGFILE=...
  74.     DATAFILE=...
  75.  
  76.     # Moving the log file will accomplish two things (for this to work,
  77.     # the LOG and DATA files must be on the same filesystem to get the
  78.     # benifit of move by linking rather than copying).  One, it will
  79.     # Isolate the data from the active log file.  The next transaction
  80.     # read in the above script will start a new log file.  Two, by
  81.     # mv'ing the file, if the logging script just happens to be in the
  82.     # middle of writing a record it will be either added, in full, to the
  83.     # DATA file (by virtue of the fact that it had the file open when
  84.     # you moved it and since you are really linking and unlinking,
  85.     # it is really still the same file so the log record will actually
  86.     # go into the renamed file), or will cause the creation of a new
  87.     # log file (if you moved it before it actually got the log file
  88.     # open).  In either case you have a full record one place or the
  89.     # other.
  90.  
  91.     mv $LOGFILE $DATAFILE
  92.  
  93.     # Wait a little while to let the log process finish writing it's
  94.     # record (in case of the obscure race condition described above).
  95.  
  96.     sleep 5
  97.  
  98.     <process the data file>
  99.     
  100. DTR should automatically track the opened status of the port (i.e.  as long
  101. as the port is open by someone, DTR will be high).  With this setup, DTR
  102. will stay high as long as the logger is running.  If the PBX in question
  103. uses DTR to determine when to send data you may have a race condition
  104. between the port being opened and the stty setting the proper modes.
  105. -- 
  106.         | Email - !shady!kevin uunet!shady!kevin kevin%shady@uunet.uu.net
  107. Kevin Smith | Voice - (+1) (908) 874-7980
  108.         | Mail  - ShadeTree Software, Inc., 192 Capricorn Dr. #10,
  109.         |         Somerville, NJ  08876, USA
  110.