Frequently asked questions

Edit online

This section includes frequently asked questions about IBM Z APM Connect.

  1. Question: What is the benefit of running the Z APM Connect Distributed Gateway on Kubernetes compared to Docker on Linux?

    Answer: Docker runs on one Linux server only. There is no ability to horizontally scale the pods across multiple servers. With Docker, you are limited to the resources of only one server. Scaling is the primary reason for choosing the Kubernetes cluster.

    To ensure optimal performance and scalability, it is recommended to deploy Z APM Connect Distributed Gateway images in either an OpenShift or CNCF Kubernetes cluster. This is particularly important when dealing with large volumes of trace data, as it enables horizontal scaling to meet changing demands.

    The Docker Standalone deployment option is only recommended for quick start evaluations.

  2. Question: Can we run multiple instances of Z APM Connect on the same LPAR with different maintenance levels?

    Answer: IBM does not recommend running multiple Z APM Connect instances on the same LPAR with different fix pack levels. If the different levels contain different IBM MQ Monitoring Subsystem levels, this approach is not possible, as an LPAR can only have one IBM MQ Monitoring Subsystem level of code only. Besides, the SAGMMOD module is concatenated in the LNKLST which contains module names at the same level. It is not possible to represent various versions with the same module names.

    It is highly recommended to use a sandbox environment to test new levels and then to move to the production environment. This way it is possible to run different levels on different LPARs.

  3. Question: Are the Z APM Connect Distributed Gateway and the Z APM Connect Base (on z/OS) mutually compatible with their previous maintenance levels?

    Answer: Unless explicitly stated otherwise, the Z APM Connect Distributed Gateway is compatible with any maintenance level of the Z APM Connect Base component on z/OS for the IBM Z APM Connect V6.1.1 release. For the latest information about the maintenance levels, refer to the IBM Z APM Connect Recommended Maintenance technote.

    Meanwhile, it is highly recommended to ensure that the maintenance of the Z APM Connect Distributed Gateway is kept up-to-date, as certain versions of the Z APM Connect Base may require a specific fix pack level of the Z APM Connect Distributed Gateway.

  4. Question: Is it recommended to have separate Z APM Connect Base tasks on the same LPAR for different applications, grouping by CICS regions?

    Answer: The answer depends on the volume of transactions generated. If the volume is high, then the recommendation would be to have multiple Z APM Connect Base tasks. If there are 10 CICS regions monitored by Z APM Connect, then the first 5 CICS regions are tied to the first Base address space and the remaining 5 tied to the second Base address space.

  5. Question: Are there any architecture limits in MQ monitoring?

    Answer: One IBM MQ is associated with one Z APM Connect Base address space. For more information about the limitations of Z APM Connect, see Known issues and limitations.

  6. Question: Is it possible to run multiple CICS regions with and without Z APM Connect enabled, while they are all connected to the same IBM MQ Manager?

    Answer: The tracking of a CICS transaction consuming an IBM MQ message is determined by the presence of a trace context in the message, such as an AppDynamics singularity header. It doesn’t matter whether the same CICS region consumes messages without headers.

  7. Question: Are there any standard reports, or performance metrics from SMF or a command to tell that the Z APM Connect is running correctly, for example, CPU, and internal memory usage?

    Answer: There is no command or report that provides details on CPU or memory usage of Z APM Connect. The AGMAPROC registers with SMF when started and unregisters when stopped, but does not generate any performance metrics. To monitor the CPU/memory usage of the AGMAPROC address space, a resource monitoring product such as OMEGAMON for z/OS is recommended.

    To display the number of events processed, and the number of z/OS address spaces, you can use the command /F AGMAPROC,AGMA CDISPLAY pid.

    To show the status of Dispatcher, Courier controller, and all Couriers, you can use the command /F AGMAPROC,AGMA STATUS ALL.

    For more information about the commands, see Base operation.