License scenarios

After the evaluation period, you must acquire a license before you can use all product features. Several different license scenarios are available. Depending on the scenario, you might need to apply licenses to IBM UrbanCode Deploy servers, agents, or both.
Important: Regardless of the license scenario that applies to your environment, each licensed agent requires a connection from each server to the Rational® Common Licensing server. Therefore, the license server must be able to have enough open connections for your topology. The total number of connections to the license server depends on how many agents and servers are running.

If you are using the IBM® License Metric Tool to monitor license usage, you must ensure that agents are connected to the server so that the correct license usage is reported. The agents get their license type from the connection to the IBM UrbanCode Deploy server. Therefore, if the agents cannot connect to the IBM UrbanCode Deploy server, the .swtag files in the agent directory might be incorrect, and as a result, the license usage reports from the License Metrics Tools might not reflect actual usage. Check firewalls and other agent connectivity issues to be sure that licenses are available and accurately accounted for.

For floating licenses, the agent holds a license during the deployment plus the waiting time.

The IBM UrbanCode Deploy server is supported on z/Linux. While the licensing component is not supported on z/Linux, IBM UrbanCode Deploy tracks agent usage, called agent high-water marks. You can use these records to estimate license use on you z/Linux installation. See Tracking agent usage.

The following license scenarios are available.

Virtual server and managed virtual server (Server Agent) licensing

In this scenario, the server and agents require separate licenses. You apply the IBM URBANCODE DEPLOY SERVER AGENT VIRTUAL SERVER license to the server and IBM URBANCODE DEPLOY SERVER AGENT MANAGED VIRTUAL SERVER licenses to the agents. If an agent does not have a license, it cannot run processes.

In this scenario, you can either allow the server to assign licenses to agents automatically or you can assign licenses to agents manually. See Applying licenses to servers and agents. The licenses are released when the agents are deleted.

UrbanCode Deploy is configured with a finite number of Server Agent licenses for an organization. When the maximum number of licenses are in use, any additional agents configured will become unlicensed and cannot run processes. Any process run on an unlicensed agent will log an error message. To resolve licensing warnings, additional licenses must be obtained, or existing licenses must be reassigned among the agents.

Processor value unit (PVU) licensing

In this scenario, you apply the IBM URBANCODE DEPLOY MANAGED CAPACITY PVU LIC license to the IBM UrbanCode Deploy server. Then, the server can run processes. In this case, the agents do not require a separate license file; instead, each PVU license allows the server to use some agents concurrently. The number of concurrent agents might be limited or unlimited, depending on the terms of the PVU license. If you are using this license scenario and the license server does not have any PVU licenses for an IBM UrbanCode Deploy server, the server cannot run processes.

You can track your use of the PVU licenses with the IBM License Metric Tool. See IBM License Metric Tool.

Virtual Processor Core value unit (VPC) licensing

In this scenario, you apply the IBM URBANCODE DEPLOY Processor Value Unit Core license to the IBM UrbanCode Deploy server. Then, the server can run processes. The most common scenario is running UrbanCode Deploy as a container in IBM Cloud Private or OpenShift. In this case, the agents do not require a separate license file; instead, each PVU license allows the server to use some agents concurrently. The number of concurrent agents might be limited or unlimited, depending on the terms of the PVU license. If you are using this license scenario and the license server does not have any PVU licenses for an IBM UrbanCode Deploy server, the server cannot run processes. For this type of licensing, the Server License Type field shows Managed Capacity. You can track your use of the PVU licenses with the IBM License Metric Tool. UrbanCode Deploy Server VPC activity can be tracked through IBM Cloud Private metering capabilities. See IBM License Metric Tool

Concurrent sessions (floating licenses)

In this scenario, the IBM URBANCODE DEPLOY SESSION PER SIMULTANEOUS SESSION LIC license is available to the agents. When an agent runs a process, the IBM UrbanCode Deploy server retrieves a license from a license server. If the first license server does not have available licenses, the IBM UrbanCode Deploy server attempts to retrieve a license from the other license servers. Regardless of whether the process succeeds or fails, 15 minutes after the process is complete, the server returns the license to the license server. The same agent that ran the process can reuse that license immediately; however, the license is not available to any other agent until the 15-minute waiting period, also called linger time, is complete.

In this scenario, the IBM UrbanCode Deploy server does not require a separate license.

Although session-based licensing is provided to accommodate fluctuations in application processing demands, peak processing demands result in more requested licenses than available. In order to avoid interruptions in deployments when a license server or servers run out of licenses, the agent is permitted to run the process and an entry is made in the error log. It is the customer's responsibility to monitor session usage and adjust licensing needs as required.

Concurrent sessions (token licenses)

In this scenario, the IBM URBANCODE DEPLOY SESSION INITIAL TOKEN 2 YEAR license is available to the agents. When an agent runs a process, the IBM UrbanCode Deploy server retrieves some token licenses from a license server. If the first license server does not have enough available licenses, the IBM UrbanCode Deploy server attempts to retrieve licenses from the other license servers. Each agent requires twenty-two tokens to run a deployment. 15 minutes after the process is complete, the server returns the licenses to the license server. In this scenario, the server does not require a license.

Although session-based licensing is provided to accommodate fluctuations in application processing demands, peak processing demands result in more requested licenses than available. In order to avoid interruptions in deployments when a license server or servers run out of licenses, the agent is permitted to run the process and an entry is made in the error log. It is the customer's responsibility to monitor session usage and adjust licensing needs as required.

Licenses for use with high-availability servers

If you use a high-availability server configuration, you might require a different license server configuration. See High-availability options for Rational License Key Server.

If you have an UrbanCode Deploy Clustered HA configuration, each of the UrbanCode Deploy Servers in that configuration will need to have an 'IBM URBANCODE DEPLOY SERVER AGENT VIRTUAL SERVER' license available for it.

Licenses for use with the blueprint design server

The blueprint designer can be used with all IBM UrbanCode Deploy license scenarios and does not require separate or extra licenses. Process requests that you initiate by provisioning a blueprint from the blueprint designer use the same agent licensing rules as requests that you initiate from the server.

Licensing for upgraded servers

If you upgraded the server from a licensed version 4.8.5, 5.0, or 6.0 to version 6.0.1 or later, the Server License Mode field is set to Disabled until you install a license server and configure a license.

Licensing for z/OS

Agents on z/OS® use different licensing scenarios than agents on distributed systems. (Agents on z/Linux use the same licensing scenarios as agents on distributed systems.) Each agent requires a license, even if multiple agents are running on a single LPAR. One agent is required on each environment, even if the environments are on a single sysplex. To run deployments, agents on z/OS must have one of the following licenses:

Feedback