Parallel Sysplex

Contents

z/OS Internet Library

This document references books that are part of the z/OS Internet Library. Please read and accept IBM's terms and conditions before using the z/OS Internet Library.

  • toggle Introduction and Planning Information

    The removal of a z/OS system from a sysplex is either a planned or unplanned activity. Operational procedures for removing a z/OS system may vary from customer to customer or from sysplex to sysplex. The documentation that follows should help you decide what procedures will work best for you.

    • toggle The XCF CLEANUP Interval (COUPLExx(CLEANUP))

      The XCF CLEANUP interval is a period of time in which XCF group members can perform clean-up for the z/OS system being removed from the sysplex. The intention of the cleanup interval is to give XCF group members on the system being removed a chance to exit gracefully from the system. The XCF CLEANUP interval only applies to planned removals of z/OS when the VARY XCF command is used to remove a z/OS system from a sysplex. XCF on the z/OS system being removed will place that system into a WAIT0A2 when either one of the following occurs:

      You can determine the value of the XCF CLEANUP interval by issuing the D XCF,COUPLE command and you can change the CLEANUP time value using the SETXCF command or by altering COUPLExx(CLEANUP) in parmlib and re-IPLing using that parmlib member.

      Some of the procedures described here wait for the CLEANUP interval to expire before proceeding with system removal. The default value for COUPLExx(CLEANUP) is 60 seconds. You should consider decreasing this timeout value in order to achieve a more expeditious removal of z/OS systems in the case of PLANNED z/OS removals. 30 seconds should be a sufficient amount of time to allow XCF group members to quiesce multi-system functions and deactivate the members.

      Recommendation
      Set COUPLExx(CLEANUP) to 30 seconds.

    • toggle Determining When a System is in a Disabled WAIT State

      The z/OS removal procedures may require that an operator recognize when z/OS is in a disabled WAIT state. How to determine when an z/OS system is in a WAIT state depends on your hardware and software configuration.

      WAIT states may be accompanied by synchronous WTOs. For example, when you VARY a system out of the sysplex the system enters a WAIT0A2. The WAIT0A2 is accompanied by synchronous WTO message IXC220W. Synchronous WTOs are special and are delivered to consoles based on your CONSOLExx DEFAULT statement SYNCHDEST parameter specification. See the following documents for additional information on SYNCHDEST:

      A synchronous WTO is one method of detecting certain WAIT states.

      Some hardware configurations will alert the operator that a WAIT state occurred by changing the color of an ICON while others may sound an alarm. You can also use the hardware panels to determine if the z/OS system is in a WAIT state.

    • toggle Performing a SYSTEM RESET

      The procedures described in this document state the need for operators to perform a SYSTEM RESET. In the context of this document, a SYSTEM RESET implies that a hardware reset function should be performed on the logical partition or CPC where the z/OS system being removed from the sysplex resides. The SYSTEM RESET is necessary to ensure that the z/OS system being removed can no longer perform any I/O operations. A SYSTEM RESET also causes an I/O RESET which causes the release of any outstanding RESERVEs and contingent allegiances. Barring z/OS access to I/O before declaring that the z/OS system is "down" ensures the integrity of data that resides on I/O devices.

      In this document, use of the term "SYSTEM RESET" implies anything that will prevent the z/OS system from doing I/O. Any of the following hardware functions will accomplish barring access to I/O devices by the z/OS system:

      When the procedures state the need for a SYSTEM RESET, if any of the above operations have been performed, consider the system reset done. For example, let's say you IPLed standalone dump before removing the z/OS system from the sysplex. The LOAD-NORMAL function that is used to IPL standalone dump performs a SYSTEM RESET as an integral part of the LOAD-NORMAL hardware operation. In this example because you will remove the z/OS system from the sysplex AFTER IPLing standalone dump, there is no need to perform a SYSTEM RESET. In fact, if you perform a SYSTEM RESET while standalone dump is running, you will terminate the standalone dump program.

      Likewise, if the hardware where the z/OS system is running loses power, there is no need to perform a SYSTEM RESET. In fact, if the hardware has no power, you can't perform a SYSTEM RESET.

      Recommendation
      Use the following software and hardware functions to reduce the need for operators to perform a System Reset and to expedite the clearing of RESERVEs and contingent allegiances.

    • toggle Sysplex Failure Management (SFM)

      The SFM "system isolation" process eliminates the need to perform a SYSTEM RESET when system isolation is successful. SFM is invoked when:

      For additional information about system isolation and SFM, see z/OS MVS Setting Up a Sysplex.

    • toggle Hardware I/O Interface Reset Facility

      The Automatic I/O Interface Reset Facility enables the operating system to reset the I/O configuration prior to putting the system into a disabled WAIT state. When z/OS loads a disabled WAIT state and this facility is invoked, the I/O interface is reset when the WAIT state is loaded.

      For more information on this facility, see

    • toggle Handling Concurrent System and Couple Data Set Failures

      In a geographically dispersed sysplex (GDPS) it is possible to have concurrent loss of couple data sets, systems, and other sysplex resources if a disaster occurs at one of the GDPS sites. Such concurrent failures are also possible in single site sysplexes. For example, a power failure can cause concurrent failure of systems and other sysplex resources without affecting all systems in the sysplex.

      Concurrent failure of one or more couple data sets and one or more systems requires a special recovery procedure. In the event that a concurrent failure occurs, XCF will issue message IXC256A. If the systems identified in message IXC256A are in an unrecoverable state (for example, disabled WAIT state, lost power), those systems must be removed from the sysplex to allow couple data set recovery to proceed. Remove each of the systems identified in IXC256A as follows:

      • 1. Perform a SYSTEM RESET on the system identified in IXC256A. (See Performing a SYSTEM RESET.)
      • 2. From an active system in the sysplex, issue

        VARY XCF,sysname,OFFLINE

        where sysname is the name of the system identified in IXC256A.
      • 3. From the SAME active system used in step 2, issue

        VARY XCF,sysname,OFFLINE,FORCE

        where sysname is the sysname used in step 2.

    • toggle z/OS Console Considerations

      When the system being removed from the sysplex contains the sysplex master (COND=M) console, ensure that the master console is switched to another system in the sysplex. To accomplish this, do one of the following:

      If the sysplex master console is not switched, message IEE141A will be issued. If the system that owned the old master console is IPLed with message IEE141A still outstanding (master console not switched or varied yet), the old master console will not activate. See APAR OW15639 for additional information.

      The consoles function of z/OS performs clean-up for a system that is removed from the sysplex after that system's removal from the sysplex is complete. Message IEA258I indicates when the console function has completed clean-up for the system that was removed from the sysplex. If you issue a ROUTE *ALL command after IXC105I but before IEA258I is issued, you will receive message IEE328I for the system that was removed from the sysplex. Consider automating on message IEA258I instead of IXC105I if your automation issues ROUTE commands.

    • toggle Other Considerations

      The D XCF,S,ALL command is useful for determining the status of a system that is being removed from the sysplex.

      When the VARY XCF command is used to partition a system out of the sysplex, message IXC371D is issued on the system where the VARY command was entered. After responding to IXC371D, system removal begins and message IXC101I is issued to indicate that XCF is removing the system from the sysplex. If more than one system exists in the sysplex, a system other than the system being removed will monitor the removal of the z/OS system.

      Message IXC101I is issued on the "monitor" system. Message IXC105I indicates when system removal is complete. This message is also issued on the monitor system. Typically the monitor system remains the same throughout the z/OS removal process. However, it is possible for the monitor process to switch from one system to another which will result in IXC101I and IXC105I being issued on different systems. For example, if the monitoring system fails before z/OS removal is complete, the monitor process may be switched to another system.

      You can issue the VARY XCF command from any system in the sysplex. When multiple systems exist in the sysplex (excluding the system being removed), the system that assumes the "monitor" responsibility is chosen randomly. Messages IXC101I and IXC105I are also issued when system removal is initiated by SFM.

  • toggle Planned Removal of z/OS Systems from a Sysplex

    The planned removal of an z/OS system from a sysplex is usually done to make hardware and/or software changes.

    Use the following steps as a guideline for creating an operational procedure for removing z/OS images from a sysplex. If you are removing a z/OS system from the sysplex and plan to take a standalone dump of that system, see Integrating Standalone Dump Procedures with System Removal Procedures. Otherwise, continue with the steps below:

    • 1. Quiesce all applications and subsystems on the z/OS system being removed from the sysplex according to your local procedures.
    • 2. Issue VARY XCF,sysname,OFFLINE where sysname is the name of the z/OS system being removed from the sysplex.
    • 3. Respond to message IXC371D to confirm the VARY XCF command. After responding to IXC371D, message IXC101I informs you that the system is being removed from the sysplex.

      The next set of actions are installation dependent:


      Otherwise, continue with step 4.
    • 4. Complete the removal of the z/OS system manually:

      Shortly after replying to message IXC371D in step 3, message IXC102A will be displayed.

      DO NOT REPLY "DOWN" TO IXC102A YET.
    • 5. Complete the removal of z/OS when SFM is active.

      If SFM is active in your sysplex, follow this step to complete the removal of the z/OS system:

      This step takes into consideration that you may or may not have a coupling facility in your configuration. If you do have a coupling facility in your configuration, this step also takes into consideration that there may be varying degrees of system-to-coupling facility connectivity in your sysplex.

      This step requires that SFM is active and that all systems in the sysplex have connectivity to the SFM couple data set. The SFM actions described in this step occur independent of the parameters that are specified in the active SFM policy (that is, you don't have to specify ISOLATETIME for these actions to occur).

      To determine if your SFM policy is active, issue the following command:

      D XCF,POL,type=SFM

    • 6. Complete the removal of the last or only z/OS system in the sysplex.

      Whether an SFM policy is active or not, you will not receive message IXC102A when removing the last system from the sysplex. Operator action is required to complete the removal of the last system from the sysplex. Automating the removal of the last z/OS system in the sysplex using SFM is not possible because the "system isolation" process requires 2 or more systems.

      OPERATOR ACTION REQUIRED:

    • toggleReinitializing Your Sysplex

      When the last system is removed from the sysplex, its data in the sysplex couple data set will indicate that the system is still active in the sysplex.

      You may receive messages IXC404I and IXC405D when you IPL a system back into the sysplex. These messages can be avoided if the first system IPLed back into the sysplex was the last system removed from the sysplex. For z/OS to positively identify the new instance of the system, it must be running NATIVE or in a PR/SM logical partition and it must be running on the same hardware that it was on when it was removed from the sysplex. See messages IXC404I and IXC405D for additional information.

      If your sysplex was not shut down in a planned manner, consider IPLing one system first. The other systems can then by IPLed simultaneously after the first system has completed global resource serialization initialization (message ISG188I for pre-STAR global resource serialization in a sysplex and message ISG300I for global resource serialization STAR).

      IPLing one system first will prevent you from having to respond to XCF/XES messages on every system.

  • toggle Unplanned Removal of z/OS Systems from a Sysplex

    The unplanned removal of an z/OS system from a sysplex usually occurs because of a failure of the z/OS system. There are two cases of unplanned removals of a z/OS system from the sysplex that will be discussed here:

    • toggle System Programmer or Operator Detected Failure

      In this case, the system programmer or operator has determined that the z/OS system is not functioning properly. However, the remaining systems in the sysplex still think that the z/OS system is active based on the fact that the system has not exceeded its missing "heartbeat" timeout interval and the fact that other systems are able to communicate with the ailing z/OS through XCF signalling. (See Automatic Detection of a z/OS Failure.)

      If attempts to recover from the failure are unsuccessful, you may decide to re-IPL the z/OS system to recover from the failure. A re-IPL of the z/OS system necessarily means that the system will be removed from the sysplex.

      Depending on the severity of the failure, you may decide to re-IPL the z/OS system immediately. Or, you may decide to defer the re-IPL of z/OS to off-peak hours. In either case, the procedure to remove the z/OS system from the sysplex is the same as the procedure used to remove an z/OS system in the case of a planned z/OS outage. See Planned Removal of z/OS Systems from a Sysplex. If you want to take a standalone dump of the z/OS system, see Integrating Standalone Dump Procedures with System Removal Procedures.

    • toggle Automatic Detection of an z/OS Failure

      This section describes two sysplex "health check" functions performed by the XCF component of z/OS:

      System Status Monitoring
      For each z/OS system, XCF updates the sysplex couple data set with status every few seconds. This "status" is sometimes referred to as a "heartbeat". For example, if you have 10 systems in a sysplex, all 10 systems update their respective "heartbeats" in the sysplex couple data set every few seconds. Each individual heartbeat consists of a timestamp.

      Besides writing the heartbeat timestamps to the sysplex couple data set, XCF on each z/OS system monitors the heartbeat timestamps of the other z/OS systems in the sysplex couple data set. If any z/OS system's heartbeat timestamp is OLDER than the current time minus that system's COUPLExx(INTERVAL) value, that system is considered to have failed in some way. When this occurs, the failed system is considered to be in a Status Update Missing (SUM) condition. All systems are notified when a SUM condition occurs. The recovery actions taken when a SUM condition occurs depends on the recovery parameters you specify for the failed system.

      The recovery parameters that you can specify to handle a SUM condition are:

    • toggle Operator Actions Required to Remove the System from the Sysplex

      When message IXC402D (recovery action: PROMPT) or message IXC102A (recovery action: ISOLATE, automatic system isolation unsuccessful) is received, do the following:

      If a standalone dump is needed, simply follow the steps in Integrating Standalone Dump Procedures with System Removal Procedures. Or, you can remove the system as follows and then initialize standalone dump.

    • toggle System-to-System Signalling Connectivity Monitoring

      Like the heartbeat monitor function described above, XCF also monitors system-to-system signalling connectivity to ensure that systems in the sysplex can communicate with each other. XCF automatically detects when signaling connectivity is lost between two or more systems. Signalling connectivity failures require either successful recovery actions to restore signalling connectivity or the removal of z/OS system(s) from the sysplex in order to regain full system-to-system signalling connectivity within the sysplex. If a system must be removed from the sysplex due to lost signalling connectivity, system removal can be accomplished in one of two ways:

      The manual and automatic procedures for removing a system from the sysplex due to lost signalling connectivity is similar to the manual and automatic procedures for removing a system from the sysplex due to a Status Update Missing (missing heartbeat) condition. Here is a summary of the actions necessary to remove a system from the sysplex due to lost system-to-system signalling connectivity:

      Manual Removal

      • 1. Reply to IXC409D and IXC417D.

        Message IXC102A is issued shortly after replying to IXC417D. DO NOT REPLY DOWN TO THIS MESSAGE YET.
      • 2. Wait for the z/OS system being removed to enter a disabled WAIT state.
      • 3. Perform a hardware SYSTEM RESET on the z/OS system being removed if not already done.
      • 4. Reply "DOWN" to IXC102A. Message IXC105I will be issued when system removal is complete.

      Automatic Removal
      To automatically remove a system from the sysplex becasue of a system-to-system signalling connectivity failure, you must have an active SFM policy that has CONNFAIL(YES) specified along with system WEIGHT assignments. Additionally, a coupling facility is required for SFM to perform system isolation. Steps 5a. and 5b. explain how system isolation works in this case with one exception; SFM does not wait for the CLEANUP interval to expire (The CLEANUP process only applies when the system is varied out of the sysplex using the VARY XCF command). For additional information, see z/OS MVS Setting Up a Sysplex.

      • 1. OPERATOR ACTION IS NOT REQUIRED FOR THIS STEP. However, you must have a contingency plan in place. See step 2.

        SFM will remove as many systems as necessary to restore full system-to-system signalling connectivity. SFM decides which system or systems to remove based on the active SFM policy. For more information, see z/OS MVS Setting Up a Sysplex. Message IXC606I will be issued to indicate that the sysplex is being reconfigured due to a signalling connectivity failure.

        Message IXC105I will be issued when system removal is complete.
      • 2. If automatic system isolation in step 1. is unsuccessful, message IXC102A will be issued for each system being removed. Do the following when this occurs:
  • toggle Automating the Removal of z/OS Systems from a Sysplex

    Recommendation
    Use Sysplex Failure Management (SFM) to automate the removal of z/OS systems from the sysplex.

    For a z/OS failure that results in a Status Update Missing condition, SFM can fully automate the actions required to remove the failed z/OS system from the sysplex. For the case where z/OS is being removed from the sysplex using the VARY XCF command, SFM can automate the actions necessary to remove the z/OS system once the VARY command has been confirmed by the operator. For system-to-system signalling connectivity failures, SFM can fully automate the actions necessary to remove z/OS systems based on your SFM policy specifications.

    NEVER automate a response to messages IXC102A or IXC402D. Before replying DOWN to these messages, a hardware SYSTEM RESET must be performed. Even if your automation is capable of performing the SYSTEM RESET, IBM recommends against doing so because the system instance that is RESET by your automation may be different from the system instance being removed from the sysplex. For example, assume that one of the systems in your sysplex is system "SYSA". Also assume that SYSA failed and that the operator IPLed standalone dump. When message IXC102A or IXC402D is issued for SYSA and your automation performs the SYSTEM RESET, the system instance being reset will be standalone dump instead of SYSA. The "system isolation" function of SFM verifies the correct system instance and performs the I/O reset when appropriate. Use SFM.

  • toggle Integrating Standalone Dump Procedures with System Removal Procedures

    Before proceeding, read "Running the SADMP Program in a Sysplex" and "Running the SADMP Program" in z/OS MVS Diagnosis: Tools and Service Aids. "Running the SADMP Program in a Sysplex" is also contained in APAR II08659.

    Taking a standalone dump of z/OS in a sysplex necessarily means that the z/OS system is being removed from the sysplex.

    The procedure that IBM recommends for taking standalone dumps of z/OS in the sysplex including the removal of that system from the sysplex is as follows:

    These are HIGH LEVEL steps (from II08659). Assume that the z/OS system being dumped and removed from the sysplex is "SYSA".

    Follow each step in order.

    • 1. Perform the hardware STOP function to place SYSA CPUs into the stopped state.
    • 2. IPL the standalone dump program
    • 3. Issue VARY XCF,SYSA,OFFLINE from another active z/OS system in the sysplex if message IXC402D or IXC102A is not already present.
    • 4. Reply DOWN to message IXC402D, IXC102A without performing a SYSTEM RESET. The SYSTEM was already RESET when SADMP was IPLed in step 2.

      Procedure "B" in II08659 is a sufficient alternative to these steps.

    The 4 steps above should be effective for all sysplex configurations (with or without coupling facilities, with or without SFM policies) with the following exceptions:

    If the system being dumped has not been removed from sysplex, you do not have to wait for the stand-alone dump to complete before issuing the VARY XCF,SYSA,OFFLINE command. Performing steps 3 and 4 immediately after IPLing stand-alone dump will expedite sysplex recovery actions for SYSA. This will allow resources held by SYSA to be cleaned up quickly - and enable other systems in the sysplex to continue processing.

    If you don't VARY the system out of the sysplex soon after you hit STOP and IPL SADMP, messages IXC402D or IXC102A will be issued because SYSA's heartbeat would have been missing for an excessive period of time. REMEMBER, if SADMP has been IPLed, reply down to either of these messages WITHOUT the SYSTEM RESET.

    Consider the following when you customize your z/OS removal and standalone dump procedures:

    • 1. A z/OS failure can be recognized by the sysplex.

      The most likely failure scenario where a standalone dump will be needed is the case where the system enters a status update missing condition and must be removed from the sysplex. For additional information, see Automatic Detection of a z/OS Failure in a Sysplex.

      If the z/OS system cannot update its heartbeat in the sysplex couple data set, there are three possible outcomes of the resulting status update missing condition:

      • 1. SFM successfully partitions the system out of the sysplex
      • 2. SFM fencing actions are unsuccessful, message IXC102A is issued
      • 3. The operator is prompted, message IXC402D is issued
    • 2. A z/OS failure can be recognized by the Operator or System Programmer.

      In this case, the operator or system programmer has determined that the z/OS system is not functioning properly. For additional information, see System Programmer or Operator Detected Failure If the system failure is such that users and application are still running OK, consider deferring taking a standalone dump until off-peak hours.

    • 3. A z/OS failure can occur during on-peak or off-peak hours of operation.

      You may want different procedures for standalone dumps of a failure that occurs on-peak versus off-peak.

      For example, for on-peak failures you may decide that it is more important to simply re-IPL certain z/OS systems rather than taking a standalone dump. Of course, in this case, valuable diagnostic data may be lost.

      Or, for on-peak failures that are not automatically detected by the sysplex, you might want to modify your procedures to VARY the failing system out of the sysplex prior to initializing standalone dump to avoid a global resource serialization ring disruption.

      If you VARY the system out of the sysplex prior to initializing standalone dump, the sysplex components of z/OS will go through their clean-up process. If the failure is associated with one of these components, the clean-up process may change or destroy valuable diagnostic information.
  • toggle Example Set of Procedures for Removing a z/OS System from the Sysplex

    Here is an example of a customized set of operational procedures for removing systems from a sysplex and taking standalone dumps if necessary:

    This set of procedures applies to:

    Assumptions:

    An active SFM policy with the following characteristics:

    CONNFAIL(YES)
    ISOLATETIME (specified for all systems in the sysplex)
    COUPLExx(CLEANUP=15 seconds) (specified for each system)

    Planned Removal of z/OS from the Sysplex, No Standalone Dump Required (VARY XCF to Remove System):

    • 1. Quiesce all applications and subsystems on the z/OS system being removed from the sysplex.
    • 2. Issue "VARY XCF,sysname,OFFLINE" where sysname is the name of the z/OS system being removed from the sysplex.
    • 3. Respond to message IXC371D to confirm the VARY XCF command. After responding to IXC371D, message IXC101I informs you that the system is being removed.

      If message IXC102A is issued for the system being removed, do the following:

      • 1. Approximately 15 (CLEANUP) seconds after IXC101I is issued, the z/OS system being removed should enter a DISABLED WAIT state. Proceed to step 3b.
      • 2. Perform a hardware SYSTEM RESET on the z/OS system being removed from the sysplex.
      • 3. Reply "DOWN" to message IXC102A.

        Message IXC105I will be issued when system removal is complete.

    Note: It's simple! With an active SFM policy and CF connectivity, all an operator needs to do is VARY the system out of the sysplex. SFM will take care of the rest

    Planned Removal of z/OS - Standalone Dump Required:

    • 1. Perform the hardware STOP function to stop all CPUs of the z/OS system to be dumped.
    • 2. IPL the standalone dump program
    • 3. If message IXC102A is already present for the system being dumped, skip to step 4. Otherwise, issue VARY XCF,sysname,OFFLINE from another active z/OS system in the sysplex to remove the failing z/OS system from the sysplex and reply to IXC371D. (Message IXC102A will only be issued if system isolation is unsuccessful, so the following steps are "contingency" steps).
    • 4. Reply DOWN to message IXC102A without doing a SYSTEM RESET.

    Note: Once you STOP the system and IPL standalone dump it is likely that the system will enter a status update missing condition. This may cause IXC102A to be issued sooner than expected, or before the VARY XCF is issued. Once standalone dump is IPLed, it is safe to reply "DOWN" to message IXC102A (or IXC402D if SFM is inactive) WITHOUT PERformING A SYSTEM RESET.

    Unplanned Removal of z/OS from the Sysplex, No Standalone Dump Required (z/OS Failure Detected by other Sysplex Systems):

    System removal is automatic using SFM with "system isolation". Otherwise, message IXC102A is issued.

    • 1. If message IXC102A is issued do the following:
    • 2. Perform a hardware SYSTEM RESET on the z/OS system being removed from the sysplex.
    • 3. Reply "DOWN" to message IXC102A.

      Message IXC105I will be issued when system removal is complete.

    No operator intervention is required. In a sysplex that has all systems connected to a coupling facility and has an SFM policy active with CONNFAIL(YES) and ISOLATETIME specified for all systems, if a system failure or a system connectivity failure occurs, SFM will automatically perform system isolation for the appropriate z/OS system(s). Steps 1 and 2 are for contingency just in case SFM system isolation is unsuccessful.

    Also worth noting is the fact that if SFM remains active with CONNFAIL(YES) and ISOLATETIME specified for all systems, you should never see messages IXC402D, IXC409D, and IXC417D.

    Unplanned Removal of z/OS - Standalone Dump Required:

    System removal is automatic using SFM with "system isolation". Otherwise, message IXC102A is issued.

    • 1. Perform the hardware STOP function to stop all CPUs of the z/OS system to be dumped.
    • 2. IPL the standalone dump program
    • 3. If message IXC102A is present for the system being dumped, reply "DOWN" to the message WITHOUT DOING A SYSTEM RESET.

    If the system being dumped was removed automatically from the sysplex by SFM, there is no need to perform a STOP (step 1) although, it will not hurt anything if you do.

Contact IBM

Browse System z


Hardware

IBM provides world-class IBM mainframe technology to help today's enterprises respond quickly to evolving business conditions and with extreme flexibility. From automation to advanced virtualization technologies and open industry standards, IBM mainframes help deliver competitive advantages for enterprises contributing and succeeding on a smarter planet.

Operating Systems

IBM System z supports multiple operation systems:

Solutions

IBM's technology, solutions and industry expertise can help you find the competitive edge with a sharper understanding of your customers. Our System z solutions combine the foundation of IBM hardware, software and middleware with flexible financing and packaging options to help your business meet and overcome the challenges of doing business in the on demand world. IBM can help you develop a customer-centric view—and assist you in delivering the right solution and the right products.


Server Time Protocol

Time Synchronization for the Next Generation