MIMIX-specific steps for an OS upgrade on the production system without switching - assure_mimix - 10.0

Use this procedure if you have more flexibility with scheduling downtime and can perform the upgrade without switching.

To perform an operating system upgrade of the production system in a MIMIX environment without switching, do the following:

1. Ensure that you have completed any prerequisite tasks for your upgrade scenario. See IBM i operating system upgrade scenarios and recommended processes for handling MIMIX during the upgrade  for a list of required tasks for different upgrade scenarios.

2. End all user applications, user interfaces, and operations actively running on the production system.

   For more information, refer to your Runbook and your applications’ user manuals.

3.  

   End the data groups from either system using the command:

   ENDDG DGDFN(*ALL) ENDOPT(*CNTRLD)

   For more information about ending data groups see Commands for ending replication.

4.  

   Wait until the status of each data group becomes inactive (red) by monitoring the status on the Work with Data Groups (WRKDG) display.

   For more information about the WRKDG display, see Displaying data group status.

5. If you have applications that use commitment control, ensure there are no open commit cycles. For more information, see Checking for open commit cycles.

   If an open commit cycle exist, restart the data group and repeat Step 3, Step 4, and Step 5 until there is no open commit cycle for any apply session.

6. Use the following command to end other MIMIX products in the installation library, end the MIMIX managers, and end the RJ links:

   ENDMMX ENDOPT(*CNTRLD) ENDRJLNK(*YES) ENDSMRJ(*YES)

7.  

   End the MIMIX subsystems on the production system and on the backup system. On each system, type the following on a command line and press Enter:

   ENDSBS SBS(MIMIXSBS) OPTION(*IMMED)

8. Complete the operating system upgrade. Allow any upgrade conversions and access path rebuilds to complete before continuing with the next step.

   Note: During the IBM i upgrade, make sure you perform a system save on the system being upgraded. This step will provide you with a backup of existing data.

9. Start the MIMIX subsystems on the production system and the backup system as you would during the synchronization phase of a switch. From each system, type the following on a command line and press Enter:

   STRSBS SBSD(MIMIXQGPL/MIMIXSBS)

10. Ensure the names of the journal receivers match the journal definitions:

    1. From the production system, specify the command:

        installation-name/WRKJRNDFN JRNDFN(QAUDJRN *LOCAL)

    2. Next to the JRNDFN(QAUDJRN *LOCAL) journal definition, specify 14 (Build) and press F4. Type *JRNDFN for the Source for values parameter and press Enter.
    3. Record the newly attached journal receiver name by placing the cursor on the posted message and pressing F1 or Help.
11. 

    Using the information you gathered in Step 10, start each data group as follows (This step also starts the MIMIX managers.):

    1. From the WRKDG display, type an 9 (Start DG) next to the data group and press Enter. The Start Data Group display appears.
    2. At the Object journal receiver prompt, specify the receiver name recorded in Step 10c.
    3. At the Object large sequence number prompt, specify *FIRST.
    4. At the Clear pending prompt, specify *YES.
12. Start any applications that you disabled prior to completing the IBM i upgrade according to your Runbook instructions. These applications are normally started in the program defined in the QSTRUPPGM system value. Allow users back on the production system.
    Note: MIMIX supports replication for up to two version level differences. If running different OS versions, Precisely recommends that the backup node run the higher OS. The following restrictions and limitations may also apply:

    • All objects must be compiled using the Target Release parameter to specify the IBM i version of the lower level operating system.

    • Possible inherent restrictions include those specific to new functionality in the OS. There may be features in a higher OS release that would not be available in a lower one, such as new command parameters or APIs.

    • Some errors may be encountered during or following a role swap due to the different OS versions.