The large number of parameter files in an TIBCO Object Service Broker installation are designed to increase flexibility and give system administrators greater control. The following sample installation should help you understand the connections among these files.
This installation has 100 users of which 15 are developers, and 85 are production users. Each of these groups needs a separate service from TIBCO Object Service Broker. This system comprises three production Data Object Brokers connected as distributed data peers, with the developers using a fourth Data Object Broker, in Perth. Production is spread over three locations: Perth, Sydney, and Melbourne. The system administrator wants to be able to shutdown and restart any of these cities’ servers as a group, and to be able to identify the servers by the names appearing in the Data Object Broker log.
The next step is to create a separate TIBCO Object Service Broker monitor process (osMon) for each Data Object Broker. Multiple osMon's can run on the same machine as long as each has a unique port and tn3270port number. An identical mon.prm file is defined for each of Perth, Sydney and Melbourne. This is the resulting mon.prm file for our installations:
The same session.prm file can be used for each location. For ease of identification, we specified a unique EENAME for each location. You use the EENAME to reference a NAME entry in the ee.prm file, discussed later.
Generally, the users of this system use the TIBCO Object Service Broker UI client, for which a parameter file is not required. The user can specify session parameters when starting the TIBCO Object Service Broker UI.
To log in using a 3270 emulator, a user supplies the host name or IP address of the machine running osMon and the osMon tn3270port number. For example, to log in to the Data Object Broker in Sydney, a user specifies the host name or IP address of the Sydney machine and a tn3270port of 9011.
Finally, an ee.prm entry must be created for each of the EENAMEs used in the session.prm.
Each Execution Environment has MAXSESSION set to 25. This does not mean that a total of 25 sessions can be supported by each Execution Environment. MAXSESSION controls the total number of sessions associated with a particular instance of that Execution Environment. Every Execution Environment can have multiple instances defined, up to the number specified by the MAXEE Execution Environment parameter. By not specifying a value for MAXEE in mon.prm, we choose to use the default value of 100. So in our example, the maximum number of sessions per Execution Environment is 100 x 25 (MAXEE x MAXSESSION) = 2500.