What infrastructure was required?

Solve:Change was designed to run on z/OS mainframe environments. It required access to specific subsystems and datasets within the mainframe environment to manage and track changes effectively. It was tightly integrated with the z/OS operating system.

For mainframe products: Did this run in an LPAR?

Solve:Change ran within an LPAR (Logical Partition) on a z/OS mainframe. It was dependent on the z/OS operating system and required specific subsystems to be active and configured correctly. It was not a standalone product and needed the mainframe environment to function.

What were the main system components?

The core components of Solve:Change included the change request management module, the approval workflow engine, and the audit trail reporting system. These components worked together to provide a comprehensive change management solution. The specific names of these components may vary.

How did users interact with the system?

Solve:Change used a combination of ISPF panels and batch jobs for user interaction and background processing. Users typically interacted with the system through 3270 terminals, using ISPF to navigate menus and enter commands. Batch jobs were used for tasks such as generating reports and processing change requests.

What was the business value of Solve:Change?

Solve:Change helped organizations reduce the risk associated with system changes by providing a structured and auditable process. This resulted in fewer errors, reduced downtime, and improved compliance with regulatory requirements. It also improved the efficiency of change management processes.

What happened if an organization did not use this product?

Without a change management system like Solve:Change, organizations faced a higher risk of errors, system outages, and compliance violations. Changes to systems could be implemented without proper planning or testing, leading to instability and potential data loss. Auditing and tracking changes became difficult.

What was the typical licensing model?

The typical licensing model for Solve:Change was likely a perpetual license with annual maintenance fees. The total cost of ownership included the initial license fee, ongoing maintenance, and the cost of training and support. Vendor lock-in was a consideration, as migrating to a different change management solution could be complex.

What security features did Solve:Change offer?

Solve:Change supported authentication through standard z/OS security mechanisms such as RACF, ACF2, or Top Secret. Access control was typically role-based, with different users having different levels of access to change management functions. Audit logging was a key security feature.

How was security handled?

Solve:Change leveraged the security features of the z/OS operating system, including RACF, ACF2, and Top Secret, for authentication and authorization. It also provided audit logging capabilities to track all changes made to the system and data. Encryption was not a primary focus.

What audit/logging capabilities existed?

Solve:Change provided audit trails that tracked all changes made to the system, including who made the change, when it was made, and what was changed. These audit logs were essential for compliance and security purposes. The logs could be used to investigate security incidents and ensure accountability.

What ongoing operational requirements existed?

Ongoing operational requirements for Solve:Change included monitoring the system for errors, performing regular maintenance tasks, and managing user access. The system required skilled mainframe operators and administrators to ensure its smooth operation. Staffing requirements depended on the size and complexity of the environment.

What were common implementation challenges?

Common implementation challenges included integrating Solve:Change with existing systems and processes, configuring the system to meet specific organizational needs, and training users on the new system. Data migration from legacy systems could also be a challenge. Careful planning and testing were essential.

What administrative interfaces were available?

Administrative interfaces for Solve:Change typically included ISPF panels and command-line interfaces. User management was handled through z/OS security systems such as RACF, ACF2, or Top Secret. Configuration parameters were stored in datasets and could be modified using ISPF editors.

Are You a Vendor? Claim Your Listing

Take control of your product listings. Add verified information, showcase updates, and unlock a Claimed Vendor badge across the directory.

Claim Your Listing Now

Solve:Change

CA Technologies Not Supported z/OS

Change Management

Vendor

CA Technologies

Product Overview

Solve:Change was a change management application designed for z/OS mainframe environments. It provided a structured framework for managing changes to systems, applications, and data. The application helped ensure that changes were implemented in a controlled and auditable manner, reducing the risk of errors and system outages.

Solve:Change leveraged ISPF panels and batch jobs for user interaction and background processing. It integrated with z/OS security systems such as RACF, ACF2, and Top Secret for authentication and authorization. Solve:Change is no longer supported.

Architects should consider alternative change management solutions such as CA Endevor, Compuware Topaz, or IBM Rational Team Concert. These alternatives offer similar capabilities and are actively supported. Migration involves a detailed architectural assessment, including integration points, security considerations, and performance requirements.

The new solution should align with the organization's overall IT architecture and support its long-term goals. Key architectural components to consider include the change request management module, the approval workflow engine, and the audit trail reporting system. The chosen solution should provide robust APIs for integration with other systems and support the organization's security policies.

Frequently Asked Questions

What did Solve:Change do?

Solve:Change was a change management system primarily used on z/OS mainframe environments. It facilitated the process of managing and tracking changes to systems, applications, and data. The goal was to ensure changes were implemented in a controlled and auditable manner.

Was this a system, application, or tool?

Solve:Change was an application designed to manage change processes. It provided a structured framework for planning, implementing, and tracking changes within an organization's IT environment. It was not a system in itself, but rather a tool to manage changes to systems.

What types of organizations used this?

Organizations that relied on mainframe systems, particularly those running z/OS, were the primary users of Solve:Change. These organizations typically operated in industries such as banking, finance, insurance, and government, where stability and controlled change management were critical.

When should an organization have considered Solve:Change?

Organizations should have considered Solve:Change when they needed a structured and auditable process for managing changes to their mainframe systems. This was especially important in highly regulated industries where compliance required detailed tracking of all system modifications.

What were the alternatives to Solve:Change?

Alternatives to Solve:Change include other change management solutions such as CA Endevor, Compuware Topaz, and IBM Rational Team Concert. These products offer similar capabilities for managing and tracking changes in software development and IT environments.

Help Improve This Directory

Notice outdated information? Have insights about this product? Help the mainframe community stay informed with accurate, current data.

Report Issue Suggest Product Share Event

Share Your Product Experience

Help the community by sharing your experience with mainframe products. Your insights help others make informed decisions.

Share Your Experience

Are You a Vendor? Claim Your Listing

Solve:Change

Product Overview

Frequently Asked Questions

What did Solve:Change do?

Was this a system, application, or tool?

What types of organizations used this?

When should an organization have considered Solve:Change?

What were the alternatives to Solve:Change?

What infrastructure was required?

For mainframe products: Did this run in an LPAR?

What were the main system components?

How did users interact with the system?

What was the business value of Solve:Change?

What happened if an organization did not use this product?

What was the typical licensing model?

What security features did Solve:Change offer?

How was security handled?

What audit/logging capabilities existed?

What ongoing operational requirements existed?

What were common implementation challenges?

What administrative interfaces were available?

Related Products

More from CA Technologies

ADC2

AutoMate

CA 90s

CA Alert/VM

CA APAS Insight

CA Automated Code Structuring for COBOL

Similar Products

ASG-TMON Change Manager for CICS

Breeze for SCLM

CA Alchemist

CA Harvest Software Change Manager

CA Netman

CA PanAPT

Help Improve This Directory

Share Your Product Experience