Files > FOUNDATIONS SITE PARAMETERS

name
FOUNDATIONS SITE PARAMETERS
number
18.01
location
^XOB(18.01,
description
This file holds the site parameters for this installation of Foundations Management and VistALink. It will have only one entry (DINUM=1) and the .01 field points to a DOMAIN that represents the name of the installation site.
applicationGroups
XOB
Fields
#NameLocationTypeDetailsIndexDescription
.01domain name(+)0;1POINTER4.2BThis 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.
.02heartbeat rate(+)0;2NUMERICThis 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
.03latency delta0;3NUMERICThis 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
.04j2ee connection timeout0;4NUMERICThis 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. BEA WebLogic: ============= DD file: weblogic-ra.xml DTD file: weblogic810-ra.dtd 1 5 1 true false 900 0 2147483647 0 0 10 0 true Oracle 9iAS: ============ DD file: oc4j-ra.xml DTD file: oc4j-connector-factories.dtd JBoss: ====== DD file: jboss-xxx-ds.xml DTD file: ?? 1 5 5000 15 For more information on each application server implementation, see documentation for each individual implementation.
.05j2ee reauthentication timeout0;5NUMERICNumber 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.
21default http timeout2;1NUMERICThis 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.
100listener configurationCONFIG;0MULTIPLE18.012This 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.

Not Referenced