Release Notes
Universal Agent release 6.9 contains the following high level features. For a complete list of all included features and fixes, please refer to the Universal Agent 6.9.x Maintenance list.
Application Integration
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. |
Universal Agent Architecture
Backlog ID | Title | Description |
---|---|---|
B-11181 | Extend password scrubbing to CSK methods | When certain command and scripts are run with embedded user ID/password information, this information can be displayed in trace statements when message_level is set to trace. The two trace points in question are:
With B-11181, the command and script lines in the offending trace statements will be replaced with *****. |
B-12001 | Universal Java networking component (used by OMS Java Client) - Modify properties referenced in code to use the new "uc." pathing initiated by the ControllerCritical | Universal Controller 6.9.0.0 modified the prefix used for properties from “opswise.” to “uc.”. The Universal Java Networking component (used by the OMS Java Client) references a subset of the Controller’s properties related to key managers and trust managers. Therefore, the Universal Java Networking Component must modify the property names it uses to the new “uc.” prefix used by the Controller. Properties in question are In file .\ua\autoctr-projects\universal\src\com\stonebranch\universal\net\UniversalTrustManager.java, function com.stonebranch.universal.net.UniversalKeyManager.UniversalKeyManager() was modified to reference the new property names:
In file .\ua\autoctr-projects\universal\src\com\stonebranch\universal\net\UniversalSession.java, function com.stonebranch.universal.net.UniversalSession.sendNegotiation() was modified to reference the new property name:
In file .\ua\autoctr-projects\universal\src\com\stonebranch\universal\net\UniversalTrustManager.java, function com.stonebranch.universal.net.UniversalTrustManager.UniversalTrustManager() was modified to reference the new property names:
|
z/OS Features
Backlog ID | Title | Description |
---|---|---|
B-11537 | z/OS UAGSRV: Extend file monitor support for secondary agents in a sysplex environment | is sprint 12 not sure it will get completed |
B-11540 | z/OS UAGSRV: Support exits issuing messages to UAG JESMSGLG, LOG and TRACE datasets | The $LOGMSG macro will allow assembler programs to issue message to the UAG LOG dataset with a severity level of INFO, DEBUG and TRACE. The appropriate log level will need to be set to allow the messages to be logged. It will allow TRACE messages with a level of ENTRY, EXIT, TRACE and WATCH. Trace will need to be active to allow the messages to be logged. For JESMSGLG messages, the message number will be 1097. The levels will be ERROR, WARN, INFO, AUDIT and TRACE. The appropriate log level will need to be set. The macro specification will allow a single text string to be sent. The assembler code line number and the issuing CSECT name will be sent as well. These will be printed in the LOG and TRACE datasets to indicate the source of the message. |
B-06132 | Recognize when a pre-allocated file is updated on z/OS (Implementation) Universal Agent 6.9.0.0 Behavioral Change Adding a z/OS File Monitor type "change" that may affect your current file monitor settings for z/OS. | Currently, UAG for z/OS uses SMF record type 15 to detect dataset creates. The same record can be used to detect updates. Create File Monitors will be modified to trigger only on creation of a dataset. Change File Monitors will be supported by having them trigger on dataset updates. Additionally, UAG for z/OS will start collecting SMF type 18 records. (These are created when a dataset is renamed.) When a dataset rename is detected which matches a Change File Monitor, the File Monitor will also trigger. For Change File Monitors, z/OS will support only the “Monitor File(s)” field in the “Agent File Monitor Details” section of the “Agent File Monitor” pane. Wildcards * and ? will be supported. For Create File Monitors, z/OS will continue to support only the “Monitor File(s)” field in the “Agent File Monitor Details” section of the “Agent File Monitor” pane. Wildcards * and ? are supported. Both Create and Change File Monitors will not be triggered until a dataset has been opened for output and then subsequently closed. Change File Monitors will also trigger when a rename of a dataset completes successfully. |
B-10813 | Suppress ICH408I message for unprivileged z/OS Agent install | Running UDM with an un-authorized User message ICH408I USER(UBRTRP ) GROUP(UBRGRP ) NAME(####################) is shown within the LOG. Even though it is an informational message confirming that the user does not have authorization, it is often considered as a "security issue" in Audits. To avoid confusion, the RACF-check, leading to thai message, will be ommited when an unauthorized user is used. |
Hybrid IT/Cloud
Backlog ID | Title | Description |
---|---|---|
B-11915 | Make all Universal Agent DNS alias comparisons case-insensitive | A customer has identified a situation in which a Universal Agent’s Access Control List (ACL) entry will not be applied if the host name portion of the entry does not match a resolved host name returned by a domain name server (DNS). According to RFC-4343, resolved host names returned from a DNS should be compared in a case-insensitive manner. The Universal Agent logic that selects ACL entries by comparing host names is currently doing a case-sensitive comparison. This means that entries that should be applied for a particular host will be bypassed, mistakenly allowing or denying access to UA components. To conform to RFC-4343, any host names compared during ACL entry processing will be treated in a case-insensitive manner. |
B-11408 | Expose Agent external/NAT IP | Since the client is not aware of its external IP, it cannot report that to the Controller in the JSS-HELLO message. However, the external IP is known by the OMS server when a client connects. What was missing is the way to report that IP from the OMS server to the Controller. However, OMS Server already has notification messages for client connection connection open/close events. The connection open event (destination=topic.oms.event.connection.open) already contains the “clientid” tag which carries the client’s queue name in the “ops.agent.AGENTID” format. The new tag “clientip” was added into the event. Its value contains the IP address of the source of client connection to the OMS server. That value is the external IP of a client if it resides behind NAT. |
New Central Licensing: UCAM
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. Tracking data will be collected by the various UAG exits and cached in the high common storage area while there is space. (The size of this area is defined by the high_common_storage configuration parameter.) Jobs will continue to run and UAGRERUN will function normally. However, job tracking, File Monitor and Syslog message information will not be processed until the Secondary receives a valid license. 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.
|