When GFE is delivered in 8.3, ISC is disabled
via the serverConfig file. You will need to have overrides in /awips/GFESuite/primary/etc/SITE/localConfig.py
in place prior to 8.3 installation which enables ISC.

For 8.2.1 sites, these new entries need to be added
in order to exchange ISC data with 8.3 sites, but the SITEgfeConfig ISC_Sites
entry needs to remain until 8.3 is installedlocally
and at all potential backup sites.

Required
Entries1. serverConfig.REQUEST_ISC = 1
This variable must be 1 to send and receive ISC data.

2. serverConfig.SEND_ISC_ON_SAVE = 1
This variable must be 1 to send ISC data as the forecasters create it.

Highly Recommended Entry1. serverConfig.REQUESTED_ISC_PARMS
= ['PARM1', 'PARM2', etc.]
If this variable is not set, every GFE element in the Fcst database will
be sent/received (everything defined between serverConfig and localConfig).
Choose which elements are important for collaboration to streamline the
ISC process and reduce unnecessary traffic. Optional Entries
1. serverConfig.REQUESTED_ISC_SITES = ['WFO1', 'WFO2', etc.] If this variable is not set, the ifpServer will automatically determine
all of the WFOs in your domain and mosaic data from them. If you wish to
receive ISC data from an RFC, this list needs to be manually created. If
you do set this manually, make sure to include your own site.

2. serverConfig.SEND_ISC_ON_PUBLISH = 1
This variable must be 1 to send ISC data when the forecasters publish.

When changes are complete, bounce
your ifpServer for them to take effect.

This sample
localConfig.py file shows most of these entries configured. It includes
all forecaster-created serverConfig parms plus ApparentT, so it can be used
to copy and paste into your own localConfig. Note:
The ISC_Sites entry in SITEgfeConfig.py is no longer needed once
all sites have loaded OB8.3. While it will not be acknowledged by the server
in 8.3, the entry needs to remain in the event an 8.2.1.1 site needs to
provide backup for an 8.3 site.

Critical Information
about Non-baseline Machines1. Under no circumstances should
the above items be configured on a non-baseline/rpp machine! This can cause
significant issues for both ISC as well as VTEC active table sharing. See
technical section for more information.

2. In the localVTECPartners.py on the non-baseline machine,
VTEC_RESPOND_TO_TABLE_REQUESTS = 0
MUST be included. This will prevent incorrect VTEC data from inadvertently
being sent to neighboring sites.

Grid Editor Changes
1. All pertinent data from surrounding sites will be included. It is no
longer clipped to a specific edit area. In ISC mode, your entire domain
will be covered with data if you have the server identify the ISC sites
(i.e. no REQUESTED_ISC_SITES entry in localConfig.py).

2. You can no longer force the send of ISC data. Surrounding
sites will need to request the data from you.

New Request
Feature for 8.2.1.1

1. Since 8.3 sites cannot force a send of
data, a new interface has been added to 8.2.1.1. This new interface allows
8.2.1.1 sites to request ISC data from 8.3 sites. While the list of sites
will include all sites registered to with the central web service, data
can only be requested from 8.3 sites. Data should only be requested when
beginning to provide service backup for a neighbor or when resuming service
after being down.

8.2.1.1 sites continue to force a send of data to surrounding sites in these
instances.

Impacts
on Service Backup

1. Scripts which populate the database
from outside of GFE do NOT send grids via ISC. This is how the backup
database is populated. So when starting to provide backup for someone,
make sure you do NOT save any data prior to the site going down as multiple
sites will be registered as the same domain.

For example, if RAH is backing up
RNK, then RAH cannot save data until RNK is down or both of them
will be sending data to surrounding sites as RNK.

2. When a site is being backed up, the surrounding
sites no longer have to route their ISC grids to the site providing
backup. The grids automatically route to the appropriate office.

3. When you begin providing backup, you will need to
populate the ISC database with data from the appropriate sites. To do
this:

ONLY use this dialog to request data when beginning service backup
or resuming operations after being down. Using this dialog during normal
operations can cause a serious drain on system resources which results
in compromised GFE performance.

Note: Even though 8.2.1 sites appear
in this list, data cannot be requested from them. ISC will still be
received from them as they save while the neighboring site is being
backed up. Those 8.2.1 sites can force a send of the database, if that
is desired.

4. VTEC active table sharing also is routed in this
fashion, so nothing special needs to occur to have hazard/VTEC information
shared during backup.

Technical/Background
Information
8.3 Sites

1. In 8.3, the way ISC work changes to use a central
web service utilizing XML to route grids to sites requesting data, rather
than each office deciding to whom to push grids. This allows for the
removal of the ISC routing info/files on dx1 as all contact happens
with the ifpServer. All needed ISC files are now part of /awips/GFESuite/primary.

2. ISC log files have also been moved to /awips/GFESuite/primary/data/logfiles
making all GFE log files together in the same location.

3. This interaction with the web service is done using
the GFE site ID, not MHS as ISC used to work (since it used dx1). This
allows for the correct routing of data when one site is backing up another.
The site performing backup registers with the web service as the failed
site which ensures ISC for that site is correctly routed to the site
performing backup. The same holds true for VTEC active table sharing.

4. The ISC configuration shown above only applies to OB8.3
sites. So OB8.3 sites cannot control what is sent to them from OB8.2.1 sites.
This is due to data from the OB8.2.1 sites missing the XML routing information.
Therefore, when received by OB8.3 sites, the data will be routed to ALL
potential ifpServers on dx4 and px3 (AFC only) with the result that many
error messages may appear in the logs as px3 will not be found anywhere
other than AFC. This will unfortunately be the case until all surrounding
sites load 8.3.

5. Local programs which utilize ISC data on a non-baseline
box will likely be affected by this new ISC routing scheme. Please be very
cautious when setting up routing of ISC data to non-baseline boxes. While
serverConfig.REQUEST_ISC = 1 can be added to the localConfig on the
non-baseline machine, serverConfig.SEND_ISC_ON_SAVE = 0 and serverConfig.SEND_ISC_ON_PUBLISH
= 0 must also be configured or those variables not configured as the
routing is dependent upon GFE ID and those machines can send out data and
corrupt ISC and VTEC data at other sites. See Critical Info
about Non-Baseline Machines in the first section. Also, the non-baseline
machine will need to be 8.3 in order to process the ISC data being sent
to it.

6. A web interface is available to the central web service.
The web interface, accessible via Mozilla on AWIPS at http://165.92.30.69:8080,
can be used to tell which ifpServers are currently registered and what elements
are requested by each site. Again, what you are requesting and what you
may receive from 8.2.1 sites could be different as ISC is still routed from
8.2.1 sites based on the SITEgfeConfig entries.

When you bring up the web interface, it looks like:

Just choose Site/Domain Configuration and leave the entry
blank and click enter. It will show ALL of the sites registered with the
server, the elements requested and sites with which ISC will occur.

7. Great care needs to be exercised when testing service
backup. All sites need to update their configuration on the central server
after getting all of the 8.3 items set. This allows real backup to work
properly. But due to these ISC changes, testing service backup for an 8.3
site can cause ISC grids to be sent. You can no longer "toggle off"
the send as you save. So while populating the database upon initiating service
backup will not send grids, any edits thereafter will. Great care needs
to be taken when testing service backup so that real operations are not
affected.

The backup GFE client can be started in PRACTICE
mode and the digital database copied using Copy All Grids From and choosing
Fcst . That is the safest testing option if formatters/tools/procedures
are to be tested for your backup site.

8.2.1 Sites

1. While the additions to the localConfig.py
file on 8.2.1 systems is primarily to correctly receive ISC data from 8.3
sites, it also allows service backup to occur between 8.2.1 and 8.3 sites.
Without those entries in the localConfig and having it uploaded to the central
backup server, the backup server could fail to start.

2. Existing ISC routing files on dx1 are still
used for OB8.2.1 sites. This means that the XML routing information received
from OB8.3 sites will be ignored. It is possible while in service backup that
duplicate ISC transmissions are received and processed from OB8.3 sites.