ITEM: AQ3599L

How to trace data output to a single tty?


ENV:    3.2.5
        mod 25T

DESC:   Using S2 tty1
        9600,none,8,1
        xon/xoff no
        RTS/CTS yes
                This tty drives a big lightboard; generates a 63byte message
        every 2-3 seconds.  The program thinks that its talking to the 
        tty but nothing is displayed.  RTS CTS and TxD are on.

        How can I trace this tty?

ACT:
        Customer wanted to trace an individual tty not a 
        particular type of device so smitty trace is overkill.

        You may be able to trace an individual tty using a named
        pipe.  In other words, instead of the application sending
        data to /dev/tty\# it would send it to /dev/ttyx and 
        /dev/ttyx would be a named pipe that would send the data to
        both a file (/tmp/ttyoutput for example) and /dev/tty\#

        This is sample code to perform this:

 
TITLE: 930616 ECHOING CONSOLE MESSAGES TO A LINE PRINTER
 What would be the best way to write error messages that are written
to the system console to also be written to a line printer? Our
consoles are ibm3151's and we lose sometimes lose messages if someone
is working on the console.
 ---------- ---------- ---------- --------- ---------- ----------
A:    I have found two ways that this can be done.  The simplest way
   is to redirect the console errors to a file with the swcons
   command.  Then, you can run two tails on this file, each one
   redirecting the tail of the file to a device.  For example:
      $ swcons /conerrors
     $ tail -f /conerrors >> /dev/lp0
     $ tail -f /conerrors >> /dev/tty0
    The first line redirects errors to a file, appends any new lines
   added to the error file to printer lp0, and the final line
   appends all additions to this file to the terminal attached to
   tty0.
    As a note, if you don't need the error messages to appear on the
   console at all, you can just redirect all errors to the printer
   with "swcons /dev/lp0".
    The disadvantage of this method is that you have a growing
   file containing errors.  You could write a cron job to
   periodically clean this file out.  Or, you could use my second
   method.  I won't go into as much detail on this one.
    First, use swcons to redirect errors to a named pipe.  Then,
   write a 5 or six line shell script to read errors from this pipe
   and echo them to the console and printer.  If you need an
   example, just ask and I will append one to this item.
 ---------- ---------- ---------- --------- ---------- ----------
Could you explain the named pipe method a little more?
 ---------- ---------- ---------- --------- ---------- ----------
      while true
      do
              if read x
              then
                      echo $x >> /dev/console
                      echo $x >> /dev/lp0
              fi
      done
   While a more robust version would be something like:
      \#!/bin/ksh
      \#-----------------------------------------------------------------
      \# This script takes input from a named pipe (or file, if you like)
      \# and sends copies to two places.
      \#
      \# This script expects three arguments:
      \#
      \#    piped .name of pipe. .first destination. .second destination.
      \# to start the transfer, or
      \#
      \#    piped -k
      \# to stop the program.
      \#
      \# This script is provided for your information only; there is
      \# no implied or explicit support for this script from IBM.
      \#
      \# key to VM symbols:  (look for \#\# at start of line)
      \#    A = Left Square Bracket       B = Right Square Bracket
      \#    C = Left Curly Brace          D = Right Curly Brace
      \#    E = Pound Sign (Shift-3)
      \#-----------------------------------------------------------------
      \# build name of file to put pid in...
      pid_file=/tmp/${0\#\#*/}.pid
      \#\#             C EE  D
      \#-----------------------------------------------------------------
      \# check to see if we are just killing off the old piped
      if [ $1 = "-k" ]
      \#\# AA           BB
      then
              kill $(cat $pid_file)
              rm $pid_file
              exit 0
      fi
      \# check for proper number of arguments otherwise
      if [ $\# != 3 ]
      \#\# AA  E      BB
      then
              print -u2 "Usage: $0 .pipe. .first dest. .second dest."
      \#\#                           A    B A          B A           B
              exit -1
      fi
      \#-----------------------------------------------------------------
      \# save our PID in a convenient location (/tmp)
      echo $$ > $pid_file
      \#-----------------------------------------------------------------
      \# open pipe for reading (just put it on standard input...)
      exec 0\< $1
      \#-----------------------------------------------------------------
      \# and loop until we are killed...
      while true
      do
              if read x
              then
                      echo $x >> $2
                      echo $x >> $3
              fi
      done
      \#-----------------------------------------------------------------
      \# should never get here, but let's make it look nice...
      exit 0

 
   Once you have the second version typed in, you will need to do the
   following:
    1. Create the named pipe:
          mknod /var/adm/err_pipe p
       You can put this pipe anywhere you like; I will use the filename
      given above in the examples here.
    2. After you create the pipe, you will need to run the above script to
      send it to the proper places:
          piped /var/adm/err_pipe /dev/lp0 /dev/console &
       This sends anything that is put into "/var/adm/err_pipe" to the
      printer device ("/dev/lp0") and to the console.
    3. Finally, you can execute a 'swcons' to the named pipe:
          swcons /var/adm/err_pipe
       Make sure this is the last step; if you try this one too early, it
      may confuse the system rather badly.
    When you are done with this arrangement, you can 'swcons' back to
   "/dev/console", then kill the 'piped' process with "piped -k".
 ---------- ---------- ---------- --------- ---------- ----------


Support Line: How to trace data output to a single tty? ITEM: AQ3599L
Dated: October 1995 Category: N/A
This HTML file was generated 99/06/24~13:30:25
Comments or suggestions? Contact us