[ |../../index.htm#lansa/l4winsb2_0360.htm]
You are here:

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.
[ |../../index.htm#lansa/l4winsb2_0360.htm]