About cookies on this site Our websites require some cookies to function properly (required). In addition, other cookies may be used with your consent to analyze site usage, improve the user experience and for advertising. For more information, please review your options. By visiting our website, you agree to our processing of information as described in IBM’sprivacy statement. To provide a smooth navigation, your cookie preferences will be shared across the IBM web domains listed here.
Last Updated: 10 April 2025
Introducing z/VM Linear Service
z/VM 7.4 delivers capabilities to help improve the service experience
What is Linear Service?
z/VM will continue to use APARs (Authorized Program Analysis Reports) as the documentation for corrective service or new function delivered in the service stream. z/VM will continue to ship code in the service stream as PTFs (Program Temporary Fixes) that will be associated to an APAR.However, with z/VM Linear Service, APARs will no longer be opened for individual z/VM problems or new features. Instead, fixes to problems will be bundled into service fix packs and new features will be bundled into feature packs. Service fixes will be delivered on a monthly basis and feature packs will be delivered twice a year.
The exceptions are hot fixes, like critical security issues, which will ship as soon as possible. Also, hardware support will be treated as a feature pack and delivered outside of the twice yearly cadence. By ordering any z/VM APAR (service fix pack, feature pack, hot fix, or hardware support) you will receive all fixes and function that has been released up to the point when the APAR was closed.
Linear Service at a glance
- z/VM will continue to ship all service as APARs.
- z/VM components will now ship four specific types of APARs:
- Service fix pack APARs are released on a regular cadence, containing all available fixes since the last released fix pack.
- Feature pack APARs are released every six months, containing new features.
- Hot fix APARs are a fix to a single high severity issue that must be addressed immediately. For example, a security issue. Issues of this type could also be communicated on the z/VM Red Alert page, depending on the severity.
- Hardware support APARs are released in support of new hardware and provide the necessary hardware toleration or exploitation.
- A z/VM APAR includes all previous service and features for the same component.
What are the details of the fix pack?
This change in the service structure for z/VM, allows customers to determine what fixes are available for a component by referencing the z/VM Change Logs. The change logs provide detailed content of the fix and feature packs and will link to the associated APAR.How can I validate what has been installed?
Validating that all systems have received the same level of service is simplified by checking the four-digit Service Level of a component. Fixes now increment the fourth digit by one, and feature packs will increment the second-digit by one and reset the fourth digit to zero on a component basis. Customers can now determine where each z/VM component is on their respective linear service timeline. Components will have independent Service Levels, meaning the Service Level of the CP component can be different from other z/VM components that aren't serviced as often or receive fewer feature packs.| Type | Schedule | Description | Service Level Impact |
|---|---|---|---|
| Service fix pack | Monthly (if needed) |
Bundle (by component) of corrective service fixes for regular issues. | Increments the fourth digit of the four-digit Service Level of the component by one. |
| Feature pack | Every 6 months (if needed) |
Bundle (by component) of new features and delivered twice a year. | Increments the second digit of the four-digit Service Level of the component by one and resets the fourth digit to zero. |
| Hot fix | When necessary | Fix for an important security or critical issue requiring an immediate solution. | Increments the fourth digit of the four-digit Service Level of the component by one. |
| Hardware support | When necessary | Support for new or updated hardware. | Increments the second digit of the four-digit Service Level of the component by one and resets the fourth digit to zero. |
Below is a hypothetical example of how the Linear Service timeline interacts with the Service Level.
| Component | Type | Service Level |
|---|---|---|
| CP | GA Release (Sep) | 0000 |
| CP | Fix pack (Sep) | 0001 |
| CP | Fix pack (Oct) | 0002 |
| CP | Hardware Support (Nov) | 0100 |
| CP | Fix Pack (Dec) | 0101 |
| CP | Feature Pack (Jan) | 0200 |
| CP | Fix pack (Apr) | 0201 |
| CP | Hot fix (Apr) | 0202 |
| CP | Fix pack (Jun) | 0203 |
| CP | Feature Pack (Aug) | 0300 |
What about the Recommended Service Upgrade (RSU)?
RSUs allow z/VM customers to apply pre-built service on their system. Traditionally, APARs were selected for the RSU by the z/VM Development team based on their importance and reliability. With Linear Service, RSUs will still be provided, but they will contain all service and features released for the system up to that point. Linear Service RSUs will precede a feature pack and will not introduce any new fixes or features by themselves. Customers may still opt to service their z/VM systems on the RSU boundary since it will provide a point on the Linear Service timeline to get all service before the introduction of the next feature pack. RSUs will update the component Service Level based on the PTFs that are applied.Are there Linear Service exceptions?
z/VM 7.3 and earlier in-service releases will remain on the non-linear "pick-and-choose" model for servicing, and will not adopt linear service. Similarly, the z/VM 7.4 and later ICKDSF and LE components do not follow the Linear Service model. Any service to these components will require assessing the available APARs and deciding which (or all) you would like to install against the component.More information
z/VM Linear Service Presentation
