Conference smaug::snagwy

# 
# Program Name: sna_ck_print
# Function:     Verify that printers configured to start via the /sbin/rc3.d/
#               S99snaps program have a valid session with the SNA Peer 
Server.
#
# Author:       R.Rose  Digital Equipment Corporation
# Date:         11/1/96
#
#
#---------------------------------------------------------------------------

# Set environment parameters
#ksh
COMMLINK=/usr/commlink
export COMMLINK
. $COMMLINK/bin/utl/commpath

# Check the size of the log file and make sure it is not getting too big.
# If /var/sna/printer.log is 500 lines or more copy it to printerlog.old and
# start a new log file.

echo "Starting Printer check..."
wc /var/sna/printer.log |cut -c8-10>/var/sna/logsize
read num </var/sna/logsize
        if [ "$num" -ge "500" ]
        then cp /var/sna/printer.log /var/sna/printerlog.old
        echo "New Printer Log started on \c" >/var/sna/printer.log
        date >>/var/sna/printer.log
        fi

# Now - make a list of all printers configured in S99snaps
#         Put this list into file: /var/sna/snatmp

cat /sbin/rc3.d/S99snaps|grep start3287 |cut -c33-38 >/var/sna/snatmp

# Now read each entry in the file and verify that pid is running.

cat /var/sna/snatmp |while read line
        do
#First check to see that *.pid file exists if not stop then start printer.

                ls -l /usr/commlink/adm/3270/$line.pid > /dev/null 2>/dev/null
                if [ "$?" -ne 0 ]
                then

echo "Printer $line had no $line.pid file as of \c" >>/var/sna/printer.log
date >>/var/sna/printer.log

#Stop the printer cleanly:
/usr/commlink/bin/3270/stop3287 $line >/dev/null 2>/dev/null

#Now restart the printer:

/usr/commlink/bin/3270/start3287 $line -p /usr/commlink/adm/3270/$line.pc 
>/dev/
null 2>/dev/null

wait

# Send message to log file that attempt was made to restart printer.

echo "Restarting Printer $line on \c" >>/var/sna/printer.log
date >>/var/sna/printer.log

# Check to see if pid is valid:

                else
#               echo $line
                read x </usr/commlink/adm/3270/$line.pid
#               echo $x
                ps -p $x >/dev/null
#                       echo $?
                        if [ "$?" -ne 0 ]
                                then
#echo "Printer $line is offline."
#Print Session is not running send message to log file.

echo "Printer $line had no active pid as of \c" >>/var/sna/printer.log
date >>/var/sna/printer.log

# Remove the old *.pid file
rm /usr/commlink/adm/3270/$line.pid >/dev/null 2>/dev/null

#Stop the printer cleanly:

/usr/commlink/bin/3270/stop3287 $line >/dev/null 2>/dev/null

#Now restart the printer:

/usr/commlink/bin/3270/start3287 $line -p /usr/commlink/adm/3270/$line.pc 
>/dev/
null 2>/dev/null

# Send message to log file that attempt was made to restart printer.

echo "Restarting Printer $line on \c" >>/var/sna/printer.log
date >>/var/sna/printer.log
                        else
                        echo "Printer $line is on line." >/dev/null
                        fi
                fi
        done

echo "Printer Check completed at \c" >>/var/sna/printer.log
date >>/var/sna/printer.log

Based on the response (actually lack of) I guess I should start the problem 
escalation process to get to someone to pay attention to this problem.

Thanks anyway,

Rich

    Re .-1
    
    You've got it. As has been said many times before this notesfile is not
    a problem reporting or escalation mechanism. It is purely for
    INFORMATION sharing.
    
    Dave

    Hi,
    
    	You should use support channels, but when you do, they might wish
    to know:
    
    1- Is your engine TPS.gwy failing?
    2- What type of gateway is your TPS engine communicating with?
    3- Do you have sna traces of the gateway? Is your IBM bouncing
    the line from time to time?
    4- Do you have Update 5 of the TPS software?
    5- Do you have TPS traces of the failures?
    
    I haven't heard of processes comming down for no reason.
    (I once heard of a watchdog problem that killed TPS engines
    by accident.  It was an "old process" watchdog that the system
    programmer had implemented, but not shared with the customer."
    
    Besides that, it has usually been the IBM's that brought down
    communications.
    
    Anything else, you'd have to get to the CSC.  Even if someone
    here knew about it, they couldn't get you a "fix". The engineers
    for this product aren't on this conference.
    
    Regards,
    Cindi