System synchronization: Planning and procedures

System synchronization is the second part of moving data between two systems.

You need to perform system synchronization if one of the following situations occurs:

• You have purchased a new system.
• You have moved all of your data to the new system.
• Or one of the following situations applies:
  • The existing system is a production system that needs to stay up and running while you convert to the new system.
  • You want to test the new system before making the switch over.

The existing system is a production system, so changes occur to the existing system do not get applied to the new system. Therefore after you have loaded the new system, you need to synchronize the new system and the existing system before you can put the new system into production.

You can perform system synchronization only if one the following conditions is true:

• The new system and the existing system are at the same release. You have fully reloaded the new system from the existing system, using Checklist 20: Recovering your entire system after a complete system loss.
• The new system is at a newer release than the existing system. You have fully reloaded the new system from the source system using one of the procedures in the Release-to-release support topic.

The method that you use to synchronize the two systems is the side-by-side method. The underlying principal of the side-by-side method is that you will run your existing system and your new system in parallel for a test period. During that test period, you will periodically perform activities to synchronize the data on your new system with the data on your existing system. At the end of the test period, you will perform final synchronization activities before moving your production work to your new system. When you complete your final synchronization, the software environment on the two systems should be identical.

The topics that follow discuss several different approaches that you can take for performing synchronization. In all cases, synchronization requires careful planning and monitoring. It also requires a good understanding of your applications and the library structure on your system. Running two systems in parallel also requires strong change-control practices. This chapter focuses primarily on synchronizing data.

If possible, during the synchronization period you should carefully limit other changes on your existing system, such as adding or changing user profiles or changing the system distribution directory. When this type of change to system customization occurs on your existing system, you need to manually perform the same updates on your new system.

You might find the security auditing function helpful for keeping track of changes to system information on your existing system. If you are not familiar with security auditing, see Auditing security on System i, which describes how to set up security auditing and which values to choose to get the entries that you need.

You can print the entries in the audit journal receiver and enter the same information on your new system.

Figure 1 provides an overview of the synchronization process. The process starts with building an initial test environment that matches a known point on your existing system (Point 1). Periodically, you establish a new known point (synchronization point) on your existing system. Point 2 and Point 3 are examples of synchronization points. After preserving any work that you have performed on your new system, such as object conversion, you use one of the synchronization methods to bring your new system to the same level as your existing system.

While you read and plan, consider how the options for synchronization relate to your current procedures (such as regular save procedures and change control procedures). By using your existing procedures as a starting point, you can reduce the level of disruption and build on your existing base of knowledge. For example, if you currently use object journaling, then object journaling might be a logical part of your synchronization strategy. If no one in your organization has experience with object journaling, then it might not be the best solution for you.