1.3.1 IBM i Master for Development?

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 are used, other developer's changes are updated into 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 PC then this requires more disk resource.

• Each Developer needs to install and update their Visual LANSA software.

Note: 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.