CA Messaging (CAM) currently supplies the underlying communication mechanisms for several TNG Components and Options.

This article focuses on CAM and, in particular, the tools and files available which allow you to control and configure this sophisticated application. A full description of all configuration parameters is beyond the scope of this article so we will only discuss those which are likely to be most relevant.

Also discussed are the log files to which CAM will write. These are ASCII files and will almost always be requested by support in the event that there is a communication problem.

CAM provides high performance, low resource utilization, reliable, scaleable application to application messaging. A CAM server process runs on each host requiring the message queuing service. Client applications connect to the server process that provides store-and-forward, routing, auditing, service level support, and hiding of data communications from its clients.

Within TNG itself, CAM is used by the OS Agent Gateway to communicate with both the NetWare and OS/2 System Agents, thus allowing them to be configured from TNG and for TNG to receive back appropriate system status information. TNG’s Performance component is another big user of CAM, using it as the means to communicate with, and receive performance information from, it’s Agents.

Within the TNG Options, CAM is currently being used by the following products:-

There are three types of CAM log files. Each class of file has a two character prefix, DG for DiaGnostic files, AU for AUdit files and TR for TRace files. The two character prefix is followed by a three digit number which, by default, increments from 000 through to 008. This number is incremented and a new file created once the preceding file reaches its predefined maximum size. After file ??008 has been filled it will cycle round to overwrite file ??000. This means that the next file after the current file will in fact contain the oldest data. The name of the current file being written to can be found in the AU_CUR (for AU files), in the DG_CUR (for DG files) or in the TR_CUR (for TR files) file. The location of these files depends on what other CA applications are installed but can usually be found at %CAI_MSQ%\logs (on NT) or $CAI_MSQ/logs (on UNIX).

The dg log files contain basic connection data and error messages.

The au log files contain nothing by default but can be enabled to collect audit data with the following commands:

The tr files contain nothing by default but tracing can be enabled by running the debug version of CAM. Before you can start the debug version of CAM you will first have to stop any applications which are currently using CAM.

E.g. to stop TNG process which are using CAM you will need to issue the following command:-

If you are running one of the TNG Options then you should shutdown that Option. E.g. if you are running Software Delivery then this would be stopped by issuing the following command:-

Once the dependent applications have been stopped you can stop CAM before restarting the debug version. This process is broadly similar across all platforms but there are some differences so the process for each platform is detailed below:-

Basic CAM statistics – listing all past and present connections with external hosts (and the protocols involved) together with a list of Applications currently using the CAM service can – can be obtained using the camstat command. An example of running camstat on an NT machine follows:-

[NT]

Host                  proto state  port  Qlen  m/sent  m/recv  retry  disc  RTO
--------------------- ----- ----- ----- ----- ------- ------- ------ ----- ----
ukwigp32.ca.com      udp   ---    4104     0       0       2      0     0    1
ukwigsb8.ca.com      udp   ---    4104     0       0       1      0     0    1
ukwies11.ca.com      udp   ---    4104     0       0       2      0     0    1
ukwigp58.ca.com      udp   ---    4104     0       0       2      0     0    1
ukwigp34.ca.com      udp   ---    4104     0       0       1      0     0    1
ukwigp24.ca.com      udp   ---    4104     0       0       5      0     0    1

Application           proto state  port  Qlen  m/sent  m/recv  retry  disc hold
---------------       ----- ----- ----- ----- ------- ------- ------ ----- ----
CAI000436-00272       tcp   CON    4105     7       0       1      0     0   60
CAIFTRANS             tcp   CON    4105     0       0       0      0     0   60

Hosts 6 - 0 cots (0 active), 6 udp, total queued 0, ave qlen 0.0
Applications 2 (2 active), total queued 7, ave qlen 3.5
Load average (m/s): send 0.00, 0.00, 0.00, receive 0.00, 0.00, 0.00
Total messages: sent 0, received 14
Supported Protocols: UDP, TCP, SPX, CAS
Local Security Level: 0

A simple CAM consistency check can be performed by running camcheck. This will check that a computer’s name agrees with its network name and that CAM can resolve its own IP address to a network name.

CAM provides a diagnostic command, camping. This can be used to establish connectivity between two cam servers. There are several possible parameters to the camping command but the most useful is perhaps the –n argument. This option will not only test the link to the remote machine but it will also signal the remote machine that it should send back details of who it thinks has just contacted it and the IP address it believes this machine resides at. E.g. running camping on an NT system might produce the following output:-

C:\>camping -n ritan01

camping: Trying 130.119.29.101 ...

Local reverse lookup gave: ritan01

CAM on "ritan01" is alive.

The remote computer identifies itself as:-

        "ritan01" at IP address 130.119.29.101

and knows this computer as:-

        "ukwigp2d" at IP address 130.119.29.129

Note: returned remote hostname differs from local reverse lookup!

This computer calls itself "ukwigp2d.ca.com" at IP address 130.119.29.129

• if camping returns a timeout error it suggests the remote machine received the message but could not reply, this may be caused by multiple network cards or firewalls (see below).
• if camping returns a network error it usually suggests that CAM cannot send to the remote machine, check DNS and host files.
• if camping is intermittent it may be that there are problems with the default protocol (see below).

CAM does not normally require any configuration once installed but there are multiple network cards or firewalls involved it may be necessary to specify the local CAM servers address. The address specified should be the address that the responding machine can reply to and is specified in the cam.cfg as follows:

If you experience unreliable communication between CAM servers then you should consider using a particular network protocol for the failing connection. This can be achieved by defining a machine/protocol entry under the PATHS section in the cam.cfg file. It is IMPORTANT that this be specified at both ends of a failing connection in order that both machines talk the same protocol. The most common protocol used in these situations is TCP. The general format to follow when defining this in the cam.cfg is as follows:-