Silent Acuthin ping

Does the acuthin "ping", (acuthin -p [servername]) support a silent mode?

Basically to run the command and return the data that is normally displayed in the display message box without the popup. 

Tags:

  • Write a program using the "C$PING" library routine. I believe there is a sample program that shows how to use it.

     

    From the documentation...

    call "C$PING" using server-to-ping, server-time [, client-data]. 
    

     

    where:

     

    server-to-ping is a PIC X(64) data item that should be filled in by the COBOL program before calling C$PING. This is the server that will be pinged.

     

    server-time is a pic 9(8) data item that is filled in by C$PING and that designates the time the server got and returned the request. Note that if this is a group item, the time is left-justified instead of right-justified (as is done via a COBOL MOVE statement). For this reason, a PIC 9(8) elementary data item is highly recommended.

     

    client-data is a PIC X(n) data item that is passed verbatim to the server. The server displays this data in the trace file (if tracing is enabled) and returns it verbatim to the client. The result is that the data in this data item is unchanged, even though it came from the server. This argument is optional.

     

    When the library routine finishes, it sets the external variable return-code to the status of the ping, as follows (these values are defined in acucobol.def.):

    78  CPING-OK                         VALUE 0. 
    78  CPING-NO-CLIENT                  VALUE 1. 
    78  CPING-PARAM-ERROR                VALUE 2. 
    78  CPING-CONN-REFUSED               VALUE 3. 
    78  CPING-VERSION-ERROR              VALUE 4. 
    78  CPING-SOCKET-ERROR               VALUE 5.
    

     

     

    CPING-OK

    everything worked, and time-at-server has a valid time from the server

    CPING-NO-CLIENT

    this runtime is not AcuServer-enabled

    CPING-PARAM-ERROR

    the COBOL program passed an invalid parameter

    CPING-CONN-REFUSED          

    the server refused the connection, possibly because it is not running or is running on a different port than the one for which the client is configured

    CPING-VERSION-ERROR

    the version of the server is not compatible with this version of the runtime

    CPING-SOCKET-ERROR

    some unknown socket error occurred

     If the server has tracing enabled, the ping request is logged in the trace file.

  • I believe "C$PING" is internal to the runtime.

    Occasionally we run into acurcl not accepting new connections. Existing runtimes continue to work but no new thin client connections can be made. We aren't aware this has happened until clients contact our support and report they can't log in.

    When this occurs I've found that the acuthin ping hangs just like "acurcl -info" and other commands run from the server prompt do. Since it has the most simplistic interface for something external to the server, it seems to be the best candidate to build a monitor out of. If I can run it silently.
  • We use a combination of things to verify that AcuConnect is responding to connection attempts.  We use monit on an external server which works by opening a telnet session to the port acurcl is running on.  

    Also, I have a shell script running via cron every 10 minutes as well.  The combo of these generally notifies of issues before we get notified.  I am going to paste a version of our script below.  Use it if you wish.  You may need to adjust pathing and such.  acurcl -info does hang when it stops accepting new connections, but it does return a result eventually.  This script uses that fact.  The -info output comes out on stderr as well...

     

    #!/bin/sh

    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    # acurclmon.sh
    #
    # This script will check on the acuconnect
    # process to ensure that it is still up and
    # accepting connections emailing someone if it
    # is not responding
    #~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    #~ CONFIG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    MAILTO="someaddress@example.com"
    MAILCC=
    TMP=/tmp/acurclproc

    #~ END CONFIG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

    # Interesting that the -info switch dumps its info
    # to stderr and not stdout...
    /usr/local/acurcl -info > $TMP 2>&1

    # All that we need is the last line. Snag it and
    # put it in the file
    strLine=$(tail -n 1 $TMP)
    print $strLine > $TMP

    OUTFILE=
    PID=
    BADDIE="n"
    # extract the PID of the host acurcl process
    PID=$(cat $TMP | sed '/^.*PID: / s///g' | sed '/\,.*/ s///')
    TSTR=$(print $PID | sed 's/[0-9]//g')

    # If we get something other than a process id, the server process may have
    # stopped responding. The output if it has stopped is usually like
    # Socket error (10020). $TSTR will be non-empty if this is the case.
    if [ "$TSTR" != "" ]; then
    BADDIE="y"
    fi

    if [ $BADDIE == "y" ]; then
    OUTFILE=$(date)" - The acurcl process does not seem to be responding correctly. You should probably check it out."
    else
    OUTFILE=$(date)" - All is good. acurcl is humming along on PID $PID"
    fi

    print $OUTFILE > $TMP
    print >> $TMP
    print "~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~" >> $TMP
    print $0 >> $TMP

    if [ $BADDIE == "y" ]; then
    if [ -z "$MAILCC" ]; then
    mail -s 'AcuRCL Process monitor' $MAILTO < $TMP
    else
    mail -s 'AcuRCL Process monitor' -c $MAILCC $MAILTO < $TMP
    fi
    fi

  • For what it's worth, in case anyone finds this thread, we are on AIX 7.1. I tuned stuff found in this article - www-01.ibm.com/.../docview.wss - and most of our issues disappeared. I do believe that AIX was not closing the stale sockets of the users who were disconnected improperly fast enough or at all.
  • Thank you, I'll take a look at that.

    As an aside I used Wireshark to trap what goes back and forth from the ping to see about duplicating. I'll post the results if I find a solution there.
  • I would be totally interested in that solution if you find one, but I had watched that exchange in Wireshark as well. It appeared that there was a little handshake that happened between the acurcl process and acuthin which would seem to indicate needing acurcl to be in a semi-sane state to mimic a "ping" in some manner. Our process was not at these times.
  • "Occasionally we run into acurcl not accepting new connections. Existing runtimes continue to work but no new thin client connections can be made. We aren't aware this has happened until clients contact our support and report they can't log in."

    We have the same problem here occasionally on multiple servers all running Centos / acurcl version 7.2.0. Every time we have to reboot our servers to solve the problem.

    What version are you using ?
  • Runtime/Acurcl version 9.1.2.1 and 9.2.5 on Centos 5/6.
  • Hi cburlon7 - thanks for your answer.

    If you are using ver. 9.2.5 I don't think it would help me upgrade my version !?

    I have used some time investigating the problem. Our servers boot with:
    acurcl -start (default port 5632)
    acurcl -start -n 5633

    All our customers use the default port 5632. I have just added port 5633 for test/investigation.

    When the problem occurs the 'acurcl -info' gives no response/hangs as you already mentioned, but 'acurcl -info -n 5633' works fine and I can still start an new application on port 5633 !

    /Henrik
  • If the problem is being caused by freed sockets being held in the wait status (as Buggabill found on AIX), then Linux has a kernel parameter that may help. Turning on tcp_tw_reuse causes the freed sockets to be reused immediately instead of waiting. Check that with:

    /sbin/sysctl net.ipv4.tcp_tw_reuse

    If it shows it is not turned on, then do:

    /sbin/sysctl -w net.ipv4.tcp_tw_reuse=1

    In the /etc/sysctl.conf file, add the following line so the setting persists after reboot:

    net.ipv4.tcp_tw_reuse = 1