...
Backlog ID | Title | Description | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| B-10715 | UA Python - Add External Module to Packaged Delivery | The following list of Python Modules and their respective Versions, used by Stonebranch-created Universal Task/Template definitions, will be included within the Python package delivered alongside Universal Agent. They do not require any further installation effort once the Agent has been installed.
No additional installation or set-up activities will be required for the Python modules listed above. |
...
Backlog ID | Title | Description | ||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| B-10873 | UAG sending License Information to Ubroker | Ensure proper license processing for Universal Broker working for a pre-Universal Agent 6.9.0.0 environment and map local license keys, as defined in UCMD and UDM Manager components to the new license structure. This is mainly to avoid unnecessary communication between a Broker and the central license managemnt component. Once the Broker has received / Aquired the License key it will handle further license requirements locall on the Broker level. | ||||||||||||||||||||||||||||||
| B-10874 | Start-up sequencing between Primary and Secondary z/OS UAGs | When a Primary agent starts, it will initialize normally (Like a non-Sysplex UAG). Additionally, it will broadcast an (internal) XCF message to all members connected to the UAG Sysplex Group. (A group that encompasses all Primary and Secondary agents in the Sysplex that share the same system_id value.) When a Secondary agent receives this message, it will reply to it. Once the Primary agent receives a reply, it will send another XCF message to the replying Secondary agent containing its license information. The Secondary agent will use this information to decide to start processing, or shut down. When a Secondary agent starts, it will initialize to the point where it can start to process. It will remain in a state where no tracking data of any kind will be processed. It will wait to be contacted by a Primary agent.
If a Primary shuts down after granting licenses to Secondary agents, all Secondary agents will return to their initial state, waiting to be contacted by the Primary. Secondaries will have to re-acquire a license when the Primary restarts. If the number of licenses has been reduced for any reason (or the number of Secondaries increased), some Secondaries will not receive a new license and will have to stop processing. Licenses are handed out by the Primary on a first come, first serve basis. In case a Secondary agent starts after the Primary agent, the Primary agent will detect the startup and broadcast the same XCF message it broadcast on startup. Processing will then proceed as described above. (Agents can detect the startup, and shutdown, of any agent in their group through XCF events that are sent to all agents connected to the group.)
| ||||||||||||||||||||||||||||||
| B-11515 | Ubroker receives UAG license Information | Implementation allows Ubroker to receive the new license information in the new MSID_BROKER_LICENSE command from the broker interface IPC. Message issued upon reception of license Information:
When GA, the above message will contain the details of the license key received. | ||||||||||||||||||||||||||||||
| B-11518 | Distribute License key, to UAC (SOA conector) when needed | The UNiversal Agent 6.9.0.0 release removes the requirement to enforce licenses based on endpoint counts. License enforcement is based solely on the following supported protocols:
A value of TRUE authorizes the protocol for use; a value of FALSE prohibits use of the protocol. The JMS, SOAP, and MQ protocols control inbound (file listener) and outbound (Web service execution) connections. If the protocol is licensed, the SOA connector is authorized to create an unlimited number of inbound or outbound connections using that protocol. The SOA connector uses the HTTP and XD SOAP for Web service execution only.
| ||||||||||||||||||||||||||||||
| B-11519 | UAGSRV: Receive new license parameters in HELLO message response | The Controller handles the JSS-HELLO message from UAGSRV and sends back the license information in the JSS-HELLO response. UAGSRV collects the information for transmission to the ubroker process. Since there is no way to check the new field existence, the following log message was added to the agent.log: "License info: CUSTOMER: <custname>, REGISTERED: YES, EXPIREDATE: <expdt>, DISTAGENTS: <cnt>, ZOSAGENTS: <cnt>, ZOSSECAGENTS: <cnt>, USAP: <conn>, UPPS: <conn>, SOA: <protocols>" JSS-HELLO message tags containing license information
Recognizing a 6.9.0.0 License: All of the new license handling implemented in the Agent requires it to know whether a new, 6.9.0.0 license was obtained from Universal Controller. If the HELLO response does not contain information for a 6.9.0.0 license, the Agent must rely on locally-configured license information. If the Agent does not receive values for the REGISTERED, LICEXPIREDATE, LICDISTAGENTS, and LICZOSAGENTS parameters, then it will behave as though it received a HELLO response from a pre-6.9.0.0 Controller and local license information is used. | ||||||||||||||||||||||||||||||
| B-11543 | Enforce startup order of autostart components so that OMS & UAG start first | Starting with Universal Agent 6.9.0.0, all licensing can, optionally, be handled by Universal Controller for Agent Management Prior to 6.9.0.0 licenses for individual agent components were stored in their respective configuration files. Aside from verifying that the license information was valid (i.e., the individual license parameters were capable of generating a key at runtime that matched the configured license key) To ensure proper startup behavior, the UA components responsible to obtaining license information (manager components) from the Controller must be started in an orderly fashion. Specifically, an OMS Server must exist to enable message exchange between the Central license management and Agent. OMS Server does not need to run on every Agent installation, but it must start first for those agents that do have it set to auto start. Next, a UAG Server must start to register with the Controller and receive the license information. All agents must now execute a UAG Server that connects to an OMS Server (B-11845), and that UAG Server must start before the Broker can proceed with its startup. After OMS Server (if necessary) and UAG Server start – and valid license information is available to the Universal Broker – the order in which the Broker starts remaining auto-start components is not important. | ||||||||||||||||||||||||||||||
| B-11544 | Ensure that Universal Broker does not open any local Service Interfaces until license Information is received | At this stage the license received from the Controller by UAG and passed to the Broker. The Broker saves the information and allows the UCMD/UDM component startup only in case if the license was received and the agent is allowed to execute jobs. Also, the current license information on the broker side is available for display in the UQUERY output. In case if UAG did not pass the license to the Controller for any reason (UAG is not connected to OMS, Controller unavailable, etc), the broker will refuse to start UDM or UCMD component with the following error: UNV3354E [1000000001] Error starting component ucmd for client 127.0.0.1:61830: CPMStartComponent, 25, License for running this component was not acquired 2020.06.24 15.48.45.455 UNV3385W [1000000001] Manager component ucmd 1593002837 (PID20045) ended with non-zero exit code 202 (000000CA). | ||||||||||||||||||||||||||||||
| B-11546 | Universal Broker to refresh local license Info with UCTRL | The Universal Control (UCTL) utility must not cause Universal Controller-obtained license information that is cached within Universal Broker to be replaced with locally-configured license information during a configuration refresh. The Universal Broker is responsible for responding to a UCTL configuration refresh request (i.e., UCTL -refresh). In its response handling, the Broker re-reads all configuration files and stores the information in its cached configuration information. When this occurs, it is not possible to prevent the Broker from re-reading and re-caching any locally-configured license information that may exist in the configuration files. However, it is possible – and necessary – to prevent the re-cached license information from being applied and enforced against license information obtained from Universal Controller. To enforce the requirement, the Broker must cache license information separately from the configuration file cache. The Broker must know the source of the license information in that separate cache. Finally, the Broker must know when license acquisition is complete, and the source of the license information to enforce is resolved. At startup, the Universal Broker always caches any locally-configured license information and maps that information to the new license parameters. This new licensing information is stored in a cache that is separate from the cache used for local configuration files. At the point where license information is merely mapped and cached, the Broker considers the license to be un-acquired (i.e., the license’s source has not been fully resolved). The Broker knows it has cached local license information, but won’t enforce that information until license acquisition completes. The Universal Broker will allow any cached, locally-configured license information to be refreshed while the license is un-acquired. The idea behind this implementation is to ensure no stale data exists when the Broker resolves the license source to use locally-configured information. If the Broker completes license acquisition and determines that locally-configured license information should be used, that Broker will allow that information to be refreshed at any time and it will enforce the refreshed information. If, at any point during its life, the Broker receives notification that UAG Server successfully connected to Universal Controller and received a 6.9.0.0 or later license, only that remote license information will be used. To prevent a UCTL refresh from overlaying this information, the Broker changes the license source from local to remote. The function within the Broker that handles the license configuration refresh sees that a remote license is being used and will immediately exit. This ensures that after a remote license is acquired, the Broker never allows a UCTL refresh to update the cached license information again. There is no situation in which a Broker will “fall-back” to using locally-configured license information after it acquires a UC 6.9.0.0 or later license. No combination of UCTL refreshes or UAG Server activity will allow remote license information to be replaced with local information. | ||||||||||||||||||||||||||||||
| B-11552 | Implementation USAP licensing based on results of B-11521 | Special Handling for USAP/UPPS Licensing Licensed execution of the Universal Connector for SAP (USAP) and Universal Connector for PeopleSoft Process Scheduler (UPPS) will be enforced using a value that represents the number of concurrent connections any USAP or UPPS component executing on behalf of a licensed agent may use at one time. Every agent as of UA 6.9.0.0, that connects to a Universal Controller 6.9.0.0 or later will receive the SAP and PeopleSoft connections that are included with the Controller’s license. The UAG Server is responsible for providing this information to its Universal Broker, which is then responsible for providing the values to the USAP and UPPS components. USAP and UPPS are responsible for defining what constitutes a unique connection. USAP and UPPS are responsible for ensuring that the number of unique connections in use at any given time do not exceed the value provided by the license. Sample Suppose that a customer purchases a license that permits 5 SAP connections. This customer has 2 6.9.0.0 Universal Agents. Each agent will receive this value (5). A USAP instance running on either agent will be permitted to use 5 unique SAP connections at the same time. An attempt to create a 6th unique connection while the other 5 are in use will fail. | ||||||||||||||||||||||||||||||
| B-11551 | Implementation UPPS licensing based on results of B-11520 | Legacy licenses did not allow to limit the connections number made by upps, i.e. the number was unlimited. The new license sends the maximum connections allowed by the license to the broker, which must keep track of all active connections and allow/reject any new connections depending on how many connections are currently active. A “connection” for UPPS is defined as the PeopleSoft Connector’s Endpoint . The license restricts the number of simultaneous unique connections performed by UPPS, meaning that the numer of sessions to the same PeopleSoft Endpoint is unlimited. | ||||||||||||||||||||||||||||||
| B-11553 | Implement USOA licensing depending on results of B-11522 | The Universal Connector for SOA (USOA) is an optional agent component that executes Web services using one of the five connection protocols or endpoints:
All that USOA needs to know is whether or not the customer purchased a license that permits Web service execution using one of the supported protocols/endpoints. Because there is no requirement for the agent to request any USOA-specific license information from the Controller, no updates to the HELLO message are needed to support USOA’s new licensing implementation. The protocols/endpoints the customer is permitted to execute will be sent via parameters in the HELLO message response. The Universal Broker will forward the value of these parameters to USOA, which is responsible for managing Web service execution based on the values it receives. | ||||||||||||||||||||||||||||||
| B-11917 | Universal Broker to check license expiration once a day | A 6.9.0.0 Universal Agent receives license information upon receipt of a UC 6.9.0.0’s HELLO message response The Universal Broker receives the license information from UAG Server The Universal Broker converts the expiration date to local time. Universal Controller licenses expire at 23:59:59 UTC The first expiration check occurs at this time, converted to local time. After the first expiration check, subsequent checks occur at 24 hour intervals. Expiration notices begin 30 days prior to the expiration date. The Universal Broker sends the expiration date to licensed components upon local registration. Each licensed component will report an expired license at startup. When a 6.9.0.0 Universal Agent (UA) connects to a 6.9.0.0 UACM(via UAG Server and OMS) it will receive license information during the HELLO message/response exchange that occurs at UAG Server startup. UC has always maintained its own license information, but in 6.9.0.0 the information it maintains is expanded to control UA licensing. This single set of license information allows the Agent to manage licensing for all of its components and eliminates the need to have licenses stored in local configuration files. UA receives a single license expiration date from the Controller and applies that expiration date to all licensed components. Although UAG Server is the direct recipient of this license information the Universal Broker is the final keeper of it, given its traditional role as owner of an agent’s local configuration. As a long-running process, the Universal Broker must implement a daily check on the license’s expiration date. Starting 30 days prior to a license’s expiration, the Broker will issue the following message when it performs its periodic check on the license: UNV0130W [] Product license expires in nn day(s). Contact Stonebranch, Inc. for license renewal. Individual licensed components will also display this message at startup. When the expiration date elapses, the Broker must ensure that no new work can start on that Universal Agent instance. The Broker and any auto-started components will continue to run, but will fail upon a check of the license’s expiration date. When a license expires, you can expect to see the following message in the Broker log and from licensed components: UNV0129E [] License is expired. Contact Stonebranch, Inc. for license renewal. Expired licenses can still be considered to be valid. Validity and expiration are handled and reported differently. Universal Agents that connect to Universal Controller whose license is expired will still receive a HELLO response. The Agent will be granted the license, provided the number of licensed agents is not exceeded. Universal Agents do not change state when a UACM license expires. Any “online” Agents will continue to show online after the license expires. However, when a UCAM license expires, it will enter a paused state, which will prevent any Universal Agent task execution. After a new license is applied, you must select the UACM Server Operations option and execute the Resume Cluster Node task. |
...