6.3.4 Rules for Repository Synchronization

The following rules summarize repository synchronization for LANSA for i and Visual LANSA:

• A fundamental part of repository synchronization is LANSA for i. Without LANSA for i, no propagations can occur.

• A Visual LANSA PC must be in a repository group or work group in order for its repository to receive any propagations. (Refer to 6.3.2 What Are Repository Groups?)

• Each Visual LANSA PC can be in only one repository group.

• A repository group contains only one Visual LANSA Repository, but could have many PCs listed if a server configuration is being used.

• When no work groups are defined, all propagations go to all repository groups. (Refer to 6.3.3 What are Work Groups?)

• A Visual LANSA PC can be in one or more work groups.

• The Host Monitor must be running on the repository gateway for changes to the current partition to be received. Propagations are queued on the IBM i until the Host Monitor is started in the appropriate partition.

• Changes to objects made by a developer using LANSA for i are not automatically propagated, but can be manually propagated. (Refer to Propagating Objects from the IBM i in the LANSA for i User Guide.)

• Changes to objects made by a developer using Visual LANSA are automatically propagated when the change is checked in to the LANSA for i Repository. (Refer to table below.)

• When LANSA messages are created, changed or deleted using LANSA for i, they are not propagated to Visual LANSA.

• When LANSA messages are created, changed or deleted using Visual LANSA, they are propagated to LANSA for i and other Visual LANSA Repositories.

• You can specify for each Visual LANSA partition how deleted objects are propagated. (Refer to 6.3.5 Synchronization Options in Visual LANSA.)

The following table summarizes how changes made to objects using the LANSA for i development environment are propagated to Visual LANSA:

Operation performed in LANSA for i Propagate to Visual LANSA Delete Object* Yes Change Object No Create Object No

 

The following table summarizes how changes made to objects using the Visual LANSA development environment are propagated to LANSA for i and other Visual LANSA Repositories:

Operation performed in Visual LANSA Propagate to LANSA for i Propagate to other Visual LANSA Repositories Delete Object* Yes Yes Change (without check-in) No No Create (without check-in) No No Check-in Changed Object Yes Yes Check-in Created Object Yes Yes

 

* Developers can control how deleted objects are propagated.

Also See

6.3.1 Repository Synchronization Concepts

6.3.7 Repository Synchronization Tips & Techniques