Skip to content
CA Gen - 8.6
Documentation powered by DocOps

Overriding Communications Support at Execution Time

Last update January 16, 2019

Generate time configuration to designate communications support for processing a specific cooperative flow when the client or proxy is generated. Execute the time configuration to designate communications type when the client application initiates a cooperative flow to a target server.

Generation Time Configuration

To designate an appropriate communications support for processing a specific cooperative flow when the client or proxy is generated.

Review the discussion in the Communications Runtime section of Anatomy of a DP Application. It is a target DPS's execution environment that dictates which transport protocol a given client can use to facilitate the processing of a cooperative flow to a given target server. At Generation Time, the communications type of a specific cooperative flow determines the Server Environment settings that are associated with the Server Manager that contains the target DPS.

The communication type that can be designated for a Server Manager corresponds to one of the supported Communications Runtimes. The following list includes communication types that can be designated for one or more Server Manager execution environments:

  • CA Gen
  • JavaRMI
  • NET Remoting
  • MQSeries
  • ECI
  • TCP/IP
  • Tuxedo
Note: CA Gen in the preceding list refers to the CA Gen Client Manager.

In addition to the communications type, any pertinent arguments that are required by the associated communications runtime can be included as part of the Server Environment settings that are associated with each Server Manager. In addition to designating the communications type, a CA Gen model contains a unique set of communications attributes that can be set for each Server Manager and its associated Procedure Steps.

A CA Gen application developer can use the Toolset or CSE Properties dialogs to specify the communications attributes for each transport.

Example:

  • Host Name and Port Number can be set for TCP/IP
  • Queue Manager and Queue Names can be set for MQSeries
  • Name Manager URL and Initial Factory can be set for EJBs
  • Tuxedo Service Name can be set for Tuxedo

The communications type and communication attributes to be used for a given flow is taken from the settings that are contained in the model and captured in generated code at the moment in time when a client application or proxy is generated. The current communication settings that are associated with a target DPS are provided to the generator. The resulting generated code contains the communications type and attribute values to be used at runtime when the client flows to the target DPS.

When the generated code is built, the communications type and associated attributes are built into the resulting application. The Generation Time Configuration provides the basis of how the application was designed to run by the application developer. The application developer generates an application to execute in a particular target execution environment.

CA Gen provides facilities to override the Generation Time Configuration at execution time. The override to the generation time configuration takes place in the client application early in the processing of a cooperative flow. The execution-time configuration is described in the following section. The circumstances in which using execution-time configuration is not possible appear in the following list:

  • A client application that is generated to use a communications type of Tuxedo
  • Server-to-Server flows that involve CICS servers
  • Server-to-Server flows that involve IMS servers
  • Server-to-Server flows that involve MQSeries Servers
  • Server-to-Server flows that involve Tuxedo

Execution Time Configuration

To designate an appropriate communications type for processing a cooperative flow when the client application initiates a flow to a target server. The ability to override the communication type at execution time eliminates the need to re-generate the client application to switch the type of transport to be used to process a given cooperative flow request.

In addition to the communication type, CA Gen lets the attributes that are associated with a selected communications type be set (or overridden) at execution time. The following bullets show two opportunities to influence the values of the communication attributes:

  • An external configuration file that is known as the Comm Config file
  • User exits invoked from each of the various Communication Runtimes

Proxies offer an API to override their Generation Time Configuration. A developer of a user-written application that use a generated CA Gen proxy can override the communications properties of the proxy by using the generated comCfg interface for that proxy.

Note: For more information about how to override a proxy communication configuration, see Working With Proxies.

Comm Config Files

Each client runtime that is provided by CA Gen accesses an external configuration file as part of its processing of a cooperative flow. This external file provides the user of a client application with the opportunity to configure its communication processing at execution time. This external file is known as the commcfg (Comm Config) file. 

The CA Gen runtime code uses the following types of commcfg files:

Each of the CA Gen client runtimes uses the specific commcfg file that are as follows:

Client Runtime commcfg File Name
MFC GUI Runtime commcfg.ini
COM Proxy commcfg.ini
C Proxy commcfg.ini
Java Web Generation commcfg.properties
Java Web View commcfg.properties
Java Proxy commcfg.properties
ASP .NET commcfg.txt
.NET Proxy commcfg.txt

About server-to-server flows, certain server execution environments support the use of the commcfg runtime override. In these cases, the server runtime uses the following commcfg file:

Server Runtime commcfg file name
EJB Runtime commcfg.properties
.NET Servers commcfg.txt

Each commcfg file provides the means of controlling certain runtime behavior including:

  • Transaction routing
  • Enabling and disabling trace activity
  • How the runtime cache the contents of the commcfg file

Transaction Routing

Transactions can be routed to a specified server execution environment by adding one or more TRANCODE lines to the commcfg file. Each TRANCODE line assigns a transaction code to a specific server execution environment.

  • Transaction codes are specified using their full name or partial name. Partial names are designated using a trailing "*" (asterisk). A single asterisk indicates all transactions. For example:
    • ABCD is a fully qualified transaction name.
    • ABC* use a wildcard to indicate that transaction routing applies to all transaction codes that begin with the letters "ABC."
    • A* use a wildcard to indicate that transaction routing applies to all transactions codes that begin with the letter "A."
      * the wildcard that indicates transaction routing applies to all transactions.
  • The arguments defining a destination for a given TRANCODE entry vary by communications type. Each communications type requires its own unique set of arguments. These arguments identify the target server execution environment. For example:
    • Host Name and Port Number for TCP/IP
    • Queue Manager and Queue Names for MQSeries

For a sample listing of the three types of commcfg files, see Comm Config Files. The syntax that is used within each commcfg file type is followed when adding TRANCODE entries. The comments section of each sample commcfg file describes the format for each of the communication types offered and supported by the execution environments that use the given commcfg file (commcfg.ini, commcfg.properties, commcfg.txt).To determine which runtime uses which commcfg file, see Comm Config Files.

The following format of a TRANCODE line is taken from a commcfg.ini file. The use of this file is intended to illustrate the general format of the TRANCODE line. The format of the TRANCODE line for the other files can be found in their respective files that are located in Comm Config Files. The format of a TRANCODE line in commcfg.ini is as follows:

TRANCODE COMMTYPE arguments

where TRANCODE and COMMTYPE are required and arguments depends on the value that is specified for COMMTYPE.

The following formats designate the type TRANCODE lines that can be entered in a commcfg.ini file:

where <...> and {...} are user supplied fields such that <...> are required fields, and {...} are optional.

<TRANCODE> TCP <host> <service/port>

<TRANCODE> ITP <host> <service/port>

<TRANCODE> MQS <Queue Name> <Queue Manager> {Reply Queue Name}

<TRANCODE> MQSC <Queue Name> <Queue Manager> {Reply Queue Name}

<TRANCODE> ECI {CICS system name}

<TRANCODE> CM

<TRANCODE> EJBRMI {Initial Factory Class}{Name Manager URL}

<TRANCODE> EJBRMI W {EAR File Name} 

<TRANCODE> EJBRMI W {Initial Factory Class} {Name Manager URL} {EAR File Name} {User Name} {Password}

<TRANCODE>=EJBRMI J {EAR File Name}

<TRANCODE>=EJBRMI J {Initial Factory Class} {Name Manager URL} {EARFileName} {UserName} {Password}

<TRANCODE> WS <baseURL> <contextType>

<TRANCODE> NET <hostName> <portNumber> <protocolCode>

Note: ITP is a version of the CA Gen TCP/IP cooperative flow-processing product that services flows to the CA Gen IMS TCP/IP Direct Connect product.

Note: For WildFly and JBoss the EAR File Name must not contain the extension '.ear'.

Some TRANCODE lines that could be coded in a commcfg.ini file are as follows:

ABCD ECI CICS22A

ABC* TCP myhost2 2008

A* CM

* TCP myhost4 2050

This illustration would route an exact trancode match of ABCD to the CICS region identified as CICS22A as defined within IBM Universal Client software. Transactions using ABCD as their trancode would use ECI as its transport mechanism. Trancodes starting with ABC (but not ABCD) would be routed to myhost2, port 2008 using TCP/IP as its transport mechanism. The Client Manager processes Trancodes that begin with A (but not ABC). All others trancodes is routed to myhost4, port 2050 using TCP/IP as its transport mechanism.

Enabling and Disabling Trace Activity

The commcfg file can be used to enable and disable tracing within the client runtimes. The CMIDEBUG statement is used to enable and disable the tracing. Usually CMIDEBUG controls tracing of the communications runtimes that is provided by CA Gen. The following CMIDEBUG statement turns on or turns off tracing activities respectively:

CMIDEBUG ON
CMIDEBUG OFF

The CMIDEBUG statement can appear multiple times within the file, but the last one encountered the setting that is in effect.

For a sample listing of the three types of commcfg files, see Comm Config Files. The syntax that is used within each commcfg file type is followed when adding a CMIDEBUG statement. The comments that are provided in each commcfg file document the syntax to be used within that file. Also, the comments identify the location of any resulting trace file that is created as a result of adding a CMIDEBUG ON statement to the commcfg file. One of the CA Gen client runtimes uses the commcfg file.

Caching the Contents of the commcfg File

The commcfg file itself can be used to indicate to each client runtime how often the runtime must re-read the commcfg. To improve performance, each runtime creats a cache of the commcfg file. By default, caching is not performed and the file is re-read and re-parsed for each flow that is processed by the client process. Re-reading the commcfg for each flow lets any file changes be applied and used for the processing of the next flow that is serviced by the runtime. This default behavior cannot be ideal in all environments. Therefore, the CACHETIMEOUT statement can be used to control the number of seconds to wait between re-reading of the commcfg file. All flows that occur between the read and the timeout use the values that are located in the cached version of the commcfg file.

Note: Rereading of the commcfg takes place after the first flow that occurs after the specified timeout value has expired.

The following CACHETIMEOUT statements set the cache timeout value to 0 (the default behavior), 3 minutes, and never:

CACHETIMEOUT 0
CACHETIMEOUT 180
CACHETIMEOUT NEVER

The specified cache timeout only applies to the client process from which a cooperative flow is initiated. If the client process terminates, the cache that is associated with that process goes away. The NEVER setting requires the client process be stopped and the communications runtime be unloaded before the commcfg file is re-read.

For a sample listing of the three types of commcfg files, see Comm Config Files. The syntax that is used within each commcfg file type is followed when adding a CACHETIMEOUT statement. The comments that are provided in each commcfg file document the syntax to be used within that file.

Runtimes User Exits

To influence how a cooperative flow will be processed by a selected communication runtime is provided by a user exit invoked by that runtime.

User exits are invoked throughout the processing of a CA Gen Distributed Processing application. User exits are invoked from within the various client runtimes, communications runtimes, and server runtimes.

For information about CA Gen user exits, see Distributed Processing User Exits. This section addresses the exits that are encountered during the processing of a CA Gen Distributed Processing application.

Was this helpful?

Please log in to post comments.

  1. Lynn Williams
    2019-01-16 09:46

    NOTE: For WildFly & JBoss "EAR File Name"/"EarFileName" must not contain the extension '.ear' The example for "sample" in the video on "https://docops.ca.com/ca-gen/8-6/en/developing/working-with-build-tool/ear-file-assembling#EARFileAssembling-WFCWildFlyConsiderations" shows that. It is already documented on this page "https://docops.ca.com/ca-gen/8-6/en/distributed-processing/working-with-enterprise-javabeans/converter-services/how-to-configure-c-to-the-java-rmi-coopflow#HowtoConfigureCtotheJavaRMICoopflow-Changecommcfg.iniFile"

    1. Chandna Mitra
      2019-01-16 11:51

      I have added a note.

      1. Lynn Williams
        2019-01-21 11:28

        Thank-you Chandna