A VTAM application program requires the exclusive use of a VTAM application definition. This definition must be stored and activated by VTAM, executing on the same machine as the VTAM application program. With the exception of the VTAM network names/ACB names assigned, VTAM application definitions can be defined identically.
VTAM requires that the ACB name be unique within a domain but allows it to be duplicated within a network. This enables pools of Execution Environment VTAM application definitions in different domains to specify the same VTAM ACB names. On the other hand, VTAM requires that network names be unique within the network.
Using this technique, the TSO EXECs or JCL used to execute Execution Environments are not dependent on the VTAM domain where they execute. In an environment of multiple VTAM domains with shared DASD or shared SPOOL, this means that CLISTs/EXECs can be shared among domains. It also means that Execution Environments that execute in batch do not have to be submitted for execution within a particular domain.
The selection of a particular prefix defines the pool of VTAM application identifiers; multiple pools in the same VTAM domain can be defined by choosing distinct prefixes.
File Execution Environment VTAM application definitions in separate VTAM major nodes. If multiple pools of Execution Environment VTAM application definitions are being used, file a separate VTAM major node for each pool.
Sample VTAM major node and logmode table definitions are included in the ASM data set. These definitions are provided to assist your VTAM systems programmer in building the definitions required by TIBCO Object Service Broker. The major nodes should be stored in SYS1.VTAMLST in all the VTAM domains within your network. The modifiable samples are distributed in the following member names:
Execution Environment VTAM application definitions are in a pool available for the general use of all Execution Environments including native Execution Environments, regardless of the intended Data Object Broker. They are allocated to Execution Environments on a first-come, first-serve basis. For more information on defining keywords in the application definition, refer to
VTAM Application Definition Keyword Operands.
Within a given VTAM domain, more than one VTAM application definition is likely required for use by Execution Environments. Use the following criteria to determine how many VTAM application definitions you need to define in a single domain:
Each Execution Environment VTAM application definition specifies a unique VTAM network name and/or VTAM ACB name as required by VTAM. VTAM supports the use of either the VTAM network name or the ACB name as the VTAM application identifier requested when the VTAM application program OPENs its VTAM ACB.
An Execution Environment selects the VTAM application identifier to use from a pool containing a range of numerically suffixed identifiers. The format of these VTAM application identifiers must follow the model that is specified by the OSEMOD installation variable
$MDL$ when TIBCO Object Service Broker is installed. An Execution Environment selects the VTAM application identifier that matches the model and has the lowest numeric suffix not already in use.
Specify the format of the application identifiers in the pool to the Execution Environments by coding the MDL parameter in the PARM
xxx members in the CNTL data set during the installation process. It is defined by the OSEMOD installation variable
$MDL$. Refer to
Appendix A, Installation Variables for details about the OSEMOD installation variables. Refer to
TIBCO Object Service Broker Parameters for additional information about the MDL Execution Environment parameter.
The first available application identifier that matches this model is selected from the pool. It is not necessary to define the model itself as a VTAM Network or ACB name.
The SMPDRVAD member in the ASM data set, described in OSB9999. OSB is the prefix that defines the pool; 9999 is the suffix that represents that a four digit number, starting at 0001, is to be used by the identifiers as they are assigned.
Use as a model the SMPDRVAD member in the ASM data set. It displays a single application definition for an Execution Environment. It also defines a pool of four VTAM application definitions, using both network and ACB names:
The Native Execution Environment requires a dedicated VTAM application definition. Since it is dedicated to the Execution Environment during execution, define a unique VTAM ACB definition for each Native Execution Environment.
|
|
Most external database gateways and the CICS Execution Environment can concurrently engage in more than one session with a Data Object Broker.
|
The member SMPLGMDE in the ASM data set contains a VTAM logmode table with general logmode table entries that specifies logical unit profiles for LU 6.1 and LU 6.2. To install a VTAM logmode table, it must be assembled and link-edited into the VTAMLIB data set. The installation procedures assume the VTAM logmode table to be installed produces a load module named OSBNCMDT in the VTAMLIB data set; this name is used in the distributed sample VTAM application definitions.
Whichever method you use to make the logmode table entries accessible to VTAM, you must specify the name of the load module as the value of the MODETAB operands. You must also specify the name of the VTAM LU 6.1 logmode table entry as the value of the DLOGMOD operands for all VTAM application definitions that support Data Object Brokers or Execution Environments.
Specifies the name of the class of service that is to be used for this session. Class of service affects the selection of a virtual route for the session and the priority of service assigned to the movement of data on the selected virtual route.
Execution Environments that select an available VTAM application definition from a particular pool are also selecting the virtual route and transmission priority associated with the class of service. Using this technique, for example, production TIBCO Object Service Broker end users could be granted the use of network resources over a different route and/or at a higher priority than test/development TIBCO Object Service Broker end users.
|
|
Specifies the level of cryptography that is to be used on the session. TIBCO Object Service Broker does not provide private cryptography. If desired and installed, VTAM cryptography can be selected.
|
|
|
Specifies the name to be assigned to the VTAM logmode table entry. The distributed sample contains an entry named HNCLUP61, which corresponds to the value of the DLOGMOD keyword operands in the distributed sample VTAM application definitions.
The names used are not significant. If a name is changed, it must correspond with one of the names used in the VTAM application definitions that are created to support the Data Object Broker and Execution Environments.
|
|
|
Specifies the primary logical unit protocols. The only PLU Protocol that is not forced by TIBCO Object Service Broker is the “chain response protocol” (bits 2 and 3). The only acceptable options for the chain response protocol are “definite response” (B'..10....') and “definite and exception response” (B'..11...'). Any other specification is converted to “definite and exception response”.
To achieve the highest communication efficiency, it is recommended that bits 2 and 3 of the PRIPROT be specified as “definite and exception response”. With this value, TIBCO Object Service Broker solicits definite responses only when protocols require it; otherwise, it solicits exception responses.
|
|
|
Specifies the primary send pacing count. To achieve configuration flexibility, it is recommended that a value of X'00' be specified for this keyword operand. This causes VTAM to use the value of the VPACING keyword for the SLU as the primary send pacing count.
|
|
|
Specifies the maximum sizes of the SNA request units that are sent by the PLU and SLU. The format of the value for this keyword operand can be found in the appropriate VTAM manual. The values that can be specified depend on the limits of the network’s capability to handle SNA request units of various sizes.
TIBCO Object Service Broker builds and transmits SNA request units within chains so that each SNA request unit is sized to its maximum according to the ability of the network to handle it, as specified by the value of this keyword operand. This yields fewer SNA request units per chain, improving communication performance.
If this keyword operand is omitted or coded with a value of 0 for either request unit size, TIBCO Object Service Broker uses the maximum request unit size as set by SNA. If too large a value is specified or defaulted, transmitted SNA request units could be rejected with sense data of X'800A' by a network node along the communication route.
|
|
|
Specifies the secondary logical unit protocols. The only SLU protocol that is not forced by TIBCO Object Service Broker is the “chain response protocol” (bits 2 and 3). The only acceptable options for the chain response protocol are “definite response” (B'..10....') and “definite and exception response” (B'..11....'). Any other specification is converted to “definite and exception response”.
To achieve the highest communication efficiency, it is recommended that bits 2 and 3 of the SECPROT be specified as “definite and exception response”. With this value, TIBCO Object Service Broker solicits definite responses only when protocols require it; otherwise, it solicits exception responses.
|
|
|
Specifies the secondary send pacing count. To achieve configuration flexibility, it is recommended that a value of X'01' be specified for this keyword operand. This causes VTAM to use the value of the VPACING keyword for the PLU as the secondary send pacing count.
|
