Disruptive

Enhanced Definition

Describes an action, change, or event within the mainframe environment that necessitates an interruption of service, such as a system restart (IPL), subsystem outage, or application downtime, to be fully implemented or resolved. It directly impacts the availability of resources or applications.

Key Characteristics

- Requires an outage: The primary characteristic is the unavoidable need for a planned or unplanned interruption of service to a system, subsystem, or application.
- Impacts availability: Directly reduces the uptime of critical mainframe resources, potentially affecting Service Level Agreements (SLAs).
- Associated with significant changes: Often linked to hardware upgrades, major software installations (e.g., new z/OS releases, product version upgrades), or critical maintenance activities.
- Requires careful planning: Due to its impact, disruptive changes demand extensive planning, scheduling, communication, and often a robust back-out strategy.
- Can be contrasted with non-disruptive operations: Many modern z/OS features and products aim for non-disruptive implementation, making disruptive changes less frequent but still necessary for certain operations.

Use Cases

- z/OS Version Upgrade: Installing a new major version of the z/OS operating system typically requires an IPL of the LPAR to activate the new system code.
- Hardware Configuration Changes: Adding or reconfiguring certain hardware components (e.g., CPU, memory, I/O channels) often necessitates an IPL of the affected LPAR(s).
- Major Subsystem Upgrades: Upgrading core components of critical subsystems like DB2, CICS, or IMS to a new major version might require a full restart of the subsystem, causing an application outage.
- Critical PTF/APAR Application: While many Program Temporary Fixes (PTFs) or Authorized Program Analysis Reports (APARs) can be applied non-disruptively, some crucial ones impacting core system components may require an IPL.

Related Concepts

Disruptive changes are central to Change Management processes, requiring rigorous planning and approval. They directly challenge High Availability (HA) and Continuous Operations goals, contrasting sharply with Non-Disruptive Operations (NDO) strategies that aim to minimize downtime. The need for disruptive actions influences Disaster Recovery (DR) planning, as recovery procedures must account for potential outages. Furthermore, the impact of disruptive events is measured against Service Level Agreements (SLAs).

Best Practices:

Thorough Testing: Always test disruptive changes extensively in a non-production environment to identify potential issues and validate the implementation process.
Detailed Back-out Plan: Develop and document a clear, tested back-out plan to revert the system to its previous state in case of unforeseen problems.
Clear Communication: Communicate the planned outage window, expected duration, and potential impact to