Remotely Running WGN

 
By Xiangbao Jing
   09/31/00
 
I had met the issue to run the WGN remotely when I was doing  the remote
text WS test for the 5.0 and porting the text WS to the Linux. And this
time Jame CCed me an Email that Wayne is trying to remotely run the WGN.
I discussed this with Jame. And I feel it is helpful if I can write down
a notes about this.

Although the AWIPS5.0 doesn't directly support the remote WGN,
but we still can do it with keeping a little problem. To do this,  we need
understand  how the communication between the d2d WGN and Text WS works?
What is the problem? How to fix it? And what is the solution?

We should look for a better communication way if we want to support "remote
WGN" in future's version.
 
The Conditions to Remotely Running WGN:
 --start d2d remotely
 --start textWS remotely
 --The temporary WGN product ID generated from d2d should be
   same as on the "$gWarnGenProduct" in the textGlobals.tcl on
   the text WS.
 
How to Communicate between the d2d WGN and Texe WS
 After creating a temporary WGN product ID for
 a message, the d2d WGN system saves the message and notices
 the text WS with this ID. Then the text WS will compares this
 received WGN ID with the a global variable, the gWarnGenProduct.
 A WGN text window will pops up if they are same, otherwise,
 nothing happens on the text WS. The key point is how to generate
 the IDs both on the d2d WGN and the text WS.
 
 When creating WGN message on d2d, the WGN system generates a
 temporary WGN product ID based on  the FXA_WARNGEN_PRODUCT_ID
 environment variable(See the WarnGenWish.C). And the
 FXA_WARNGEN_PRODUCT_ID is set  when installing the the system
 (See the siteConfig/environs/post.install_wfoa.sh). It sets NNNXXX
 to WRKWG#. The # is workstation number based on the AWIPS host
 name, it is the first digit in the host name actionally.
 NNNXX will be WRKADM if there is no 1 to 9 digit in the name.
 
 When running the text WS, a global variable gWarnGenProduct in TCL
 is set based on the first digital in the DISPLAY which includes
 a host name and a screen name. NNNXX will be WRKADM if there is no
 1 to 9 digital in the name. See the textGlobals.tcl in detail.
 
 This design is OK for running both the WGN and text WS locally and
 both have same workstation numbers, but remotely.
 
 
 
 
Problem1:
 The ways to create the WGN product ID are different in the d2d
 and the text WS. The d2d uses the WS Number and the text WS uses the
 DISPLAY environment variable. So, the WGN product IDs of the d2d and
 text WS are different when running the WGN system remotely, because
 the host name and screen name in the DISPLAY is local in this case.
 
Solution:
 Before running the d2d remotely, reset the FXA_WARNGEN_PRODUCT_ID to
 WRKWG# on the remote node. The # should be the the first digital in the
 local workstation name, in the other words, it is the local workstation
 number. There are three cases,
  --Use the workstation number, if the name of the local WS
    is standard AWIPS WS name, like ws2-bou.
  --Set the # to the screen number if there isn't any digital of
    1 to 9 in the name of the local WS. For example, if the local
    WS is smew, the screen number is 0, then the DISPLAY is
    smew:0.0, so, set the # to 0; if the screen is 1.0, set the
    # to 1.
  --Use the first digital if use an IP number to set DISPLAY.
    For example, the DISPLAY is 137.23.23.1:0.0, set the # to 1.
 
Problem2:
 Another problem is that the a WGN text window pops up on another remote
 text WS also. For exaample, the remote workstations are the ws1-bou,
 xt1-bou, ws2-bou, xt2-bou. If both the xt1-bou and xt2-bou are running
 the textWS system, and from the local ws2-fsl we rlogin to the remote
 node ws1-bou, then remotely run a text WS and d2d, and display them on
 the local node ws1-fsl. In this case, the WGN text Window will pop up
 on the remote node xt2-bou too, is not only on the screen of ws2-fsl.
 Because we set the FXA_WARNGEN_PRODUCT_ID = WRKWG2 on the ws1-bou, the
 WGN genretes a CCCWRKWG2 ID for a WGN message, the text WS systems on
 the ws1-bou and xt2-bou both set the gWarnGenProduct to CCCWRKWG2.
 
 I can't fix the problem until we redesign the communication way between
 the d2d WGN process and the text WS.

 
 
When installing the AWIPS WS
----------------------------
siteConfig/environs/post.install_wfoa.sh

...
# If this is a workstation, warngen will store to this work product:
# (e.g., WRKWG1).  We generate a workstation number from the
# first numeric digit in the hostname.  We now rely on default CCC,
# rather than setting it explicitly here. [MRB 8/6/97]
# The following should work for both AWIPS and FSL.
ws_num=`hostname | tr -d -c '[0-9]\n' | cut -c1`
if [ "x$ws_num" = "x" ] ; then ws_num=0 ; fi
FXA_WARNGEN_PRODUCT_ID=WRKWG${ws_num}
export FXA_WARNGEN_PRODUCT_ID

...
 

In the WarnGenWish.C on the d2d
-------------------------------
...
// Generate the product name under which to store.
    // If environment variable FXA_WARNGEN_PRODUCT_ID is defined,
    // use that; otherwise usee DENWRKADM.  A better mechanism is needed
    // for this, but this will do for now.
    char *product_id = getenv("FXA_WARNGEN_PRODUCT_ID");
    if (product_id == 0)
        product_id = "DENWRKADM";
...
 
 
 

In the textGlobals.tcl on the text WS
--------------------------------------
set gWarnGenProduct $gLocalSiteCCC
append gWarnGenProduct WRKWG$n
...
# Product id to be stored by WARNGEN
# We'll try to pull a workstation number out of the display name, by looking
# for the first numeric digit.  So if the display is DENTEXT3:0.0 or
# WS3_NHDA:1.0, we'll find 3.
set n 0
for { set i 0 } { $i < [string length $env(DISPLAY)] } { incr i } {
    set char [string index $env(DISPLAY) $i]
    if [string match {[0-9]} $char ] {
        set n $char
        break
    }
}