View Source

Visual LANSA Version 15 > 1.3.1 IBM i Master for Development > 1 2 1 ibm i slave systems.png

Pros

IBM i centric development. It's the model of choice for development shops with a major focus on IBM i.
Existing IBM i change management systems may be used.
Can develop without a connection to the Master System.
It's the model you've been using.
The LANSA development team has used this model extensively for developing LANSA in LANSA. (Not sharing the database with Repository Synchronization.)
All developers can be kept up to date using Repository Synchronization.
Using Individual PC databases and Repository Synchronization together provides for some control over receiving other developer's changes as they are only received when connecting to Host Monitor.

Cons

The Master System must be available when installing the IBM i Slave and whenever system data needs to be updated. (System Initialization and Partition Initialization).
The Master System must be available to obtain permission to modify an object (Check Out) and to make those changes available to other developers (Check In).
When the database is shared or Repository Synchronization is used, other developer's changes are updated in a developer's environment according to the schedule of the other developer. They are not obtained on demand. That is, the developer is not sandboxed.
If the database is installed on each Developer's PC then this requires more disk resources.
Each Developer needs to install and update their Visual LANSA software.

The redundancy afforded by having the Master System reduces the importance of backing up individual PC databases. If a PC database is lost, then only the changes up to the last check in will be lost. If developer's check in frequently then little is exposed.