6.3.1 Repository Synchronization Concepts
Repository Synchronization is a feature that allows changes made to a LANSA for iSeries Master Repository to be propagated to Visual LANSA Slave Repositories in order to maintain current object and system information in the Slave Repositories. For example, if a Visual LANSA developer checks in a new field to the LANSA for iSeries Repository, the list of fields shown in other Visual LANSA Repositories would need to be updated in order to match the LANSA for iSeries Master System.
Repository Groups are set up in LANSA for iSeries to reflect how the Visual LANSA repositories are connected to the iSeries repository so that information can be automatically propagated from the iSeries to the Visual LANSA repositories. The propagated information consists of changes to task tracking and partitions on the iSeries, updated information checked in to the iSeries by a member of a work group, and any user initiated requests from the main development environment "work with" panels on the iSeries.
Not all types of changes to objects made by a developer on the iSeries are automatically propagated, but the changes may be manually propagated. For example, if a field is created by a developer using LANSA for iSeries, this new field is not automatically propagated to Visual LANSA. Also, when a developer using Visual LANSA creates a field, it is not automatically propagated. But when a Visual LANSA developer checks-in a new field to the LANSA for iSeries Repository, this change is automatically propagated to other Visual LANSA Repositories. Repository synchronization is based upon a Visual LANSA centric development model where LANSA for iSeries hosts the master repository but all development work is performed using Visual LANSA workstations. (Refer to 6.3.4 Rules for Repository Synchronization.)
A change is propagated by automatically sending a check out for read-only transaction to a slave workstation. Note that if an object is checked out for update in a Visual LANSA Repository, the propagation still overwrites this object. Thus, it is recommended that only one user updates an object at any one time. (Refer to 6.2 Using Task Tracking in LANSA and Task Tracking and Repository Synchronization for more information.) A user on this Visual LANSA Repository would need to check the object out for update again in order to be able to modify it. Remember, check out is always partition-specific. Objects are only checked out to the allowed partitions defined in the PC definition of the member.
A manual developer option also exists in LANSA for iSeries to propagate changes. Refer to Propagating Objects from the iSeries and the Host Monitor.
Also See
LANSA PC Development in the