|.01||domain name(+)||0;1||POINTER||4.2||B||This is the domain name of this installation of the Foundations and VistALink application as it is known to the rest of the network. This name applies to all CPUs or Volume sets which access this ^XOB global and the ^XWB global.|
|.02||heartbeat rate(+)||0;2||NUMERIC||This field indicates the rate (in seconds) the VistALink heartbeat message should be expected from a client. If there is no activity on the connection for this amount of time, the client will send a system heartbeat message. The client, as part of the initial connection protocol, retrieves this value. As a result, the client and the M server are always synchronized regarding the heartbeat rate. See also: LATENCY DELTA|
|.03||latency delta||0;3||NUMERIC||This field indicates the number of seconds to add to the HEARTBEAT RATE when calculating the initial timeout value for the VistALink Listener. The client and the M server are synchronized regarding the HEARTBEAT RATE. This latency parameter allows the site to fine tune the timeout value. The site can to take into account any network slowness or other factors that may delay the arrival of the system heartbeat message from the client. See also: HEARTBEAT RATE|
|.04||j2ee connection timeout||0;4||NUMERIC||This field indicates the number of seconds that a VistaLink connection
from J2EE to M should be allowed to remain connected but inactive, before
M drops the connection.
It is recommended that this J2EE CONNECTION TIMEOUT
parameter be set relatively high, for example 1 day (86400 seconds).
A high setting is recommended because all the major application
server implementations have more robust mechanisms for controlling
connection pools. The site should use the tools/mechanisms supplied
by the application server implementation to control how the connection
pool size grows and shrinks.
For a quick indicator of the level of control available, below is a
brief summary of the connection pool properties in the J2EE
deployment descriptors (DD) for J2EE Connector Architecture (J2CA)
adaptors by the major application servers.
DD file: weblogic-ra.xml
DTD file: weblogic810-ra.dtd
|.05||j2ee reauthentication timeout||0;5||NUMERIC||Number of seconds a connection is considered reauthenicated after a successful reauthentication has occurred. Rules Enforced: =============== - If a connection in the application server's pool is not reused by the reauthenticated user before this timeout limit is reached, the reauthentication is considered expired. - If expiration does occur, the re-authentication process is performed again. - If expiration does not occur, the session is considered reauthenticated for these number of seconds. (i.e. the time out clock is reset) - If a different user gains access to the connection, the connection is immediately considered not reauthenticated and the reauthentication process is performed. Example of Reauthentication Expiration: ======================================= - User gains access and uses a connection from the pool at 4:00pm - User signs off and goes home, along with most of the site staff - After 4:00pm, user file maintenance is performed and the user's profile is changed. For example, the user's FILE MANAGER ACCESS CODE [DUZ(0)] is changed. - User signs back on the next morning at 8am - Since there is very little activity from 4:00-8am, the connection has not been re-used by another user and is still associated with 4:00 user - Since timeout has passed, reauthentication has expired - Reauthentication process occurs for user - Reauthentication process re-sets DUZ(0) appropriately to new value.|
|21||default http timeout||2;1||NUMERIC||This field indicates the default HTTP time-out (in seconds) for call out of the M to a J2EE application server using the M2J feature in VistALink. This time-out value can be overridden by specifying a time-out for an particular application server. This is accomplished by entering a time-out value for DEFAULT HTTP TIMEOUT (#.1) field in the VISTALINK J2EE APP SERVERS (#18.08) file. Note: This field is only used by the VistALink v2.0 codebase.|
|100||listener configuration||CONFIG;0||MULTIPLE||18.012||This multiple field contains the VistALink Listener configurations for BOX-VOLUME entries in the DOMAIN NAME's scope. Each configuration is used by the XOBV LISTENER STARTUP menu option. This option is typically scheduled to run as part of the system startup after the VistA system has been restarted. The option will start up VistALink Listeners for the BOX-VOLUME where Task Manager is running. Note: This only applies to Cache NT systems. VMS/DSM systems need to use the TCP/IP (UCX) utility to have Listeners automatically started on reboot.|