MKS Implementer 2006 Administration Guide

Performance Considerations
Multiple System Development
You must analyze the performance impact of this feature on the secondary systems to
determine its feasibility within your system setup. Some of the database files opened on the
secondary system are DDM files. To effectively use this feature you need high-speed
transmissions, such as that provided by a Gigabit Ethernet. The secondary systems using
Implementer with DDM files do not significantly affect the primary system.
Additionally, to enable the secondary system to use Implementer, the communications line to
the primary system must be active and the Implementer database files on the primary system
must be available. If the line to the primary system goes down, Implementer on the
secondary system is unavailable for use until you re-establish the connection.
If your communication line cannot provide adequate performance when you convert the
Implementer files to remote databases, you may want only certain functional areas of the
product to use this feature. On the Start Remote Database command, the default is to convert
all files; however, you can specify to convert only the files related to lock and conflict
processing [FILESCVT(*LOCKS)]. If you specify *LOCKS, each system operates with most
Implementer files locally, yet maintains one set of files that enforce, lock, and allow
concurrent development across all systems.
Specify *PROJECTS to have one project tracking database. You can specify one or more of
these values in the FILESCVT list. If you specify *ALL anywhere in the list, it overrides
*LOCKS and/or *PROJECTS.
Request Number Considerations
If you use multiple system development and do not convert all database files, you should
adjust the request number on each secondary system to avoid conflict with the request
numbers on the primary system. For example, if the next request number (in System Control
Maintenance) on the primary system is 500, set the next request number on a single
secondary system to 5500. For multiple secondary systems, the next request numbers can be
divided into equal groups depending on the number of secondary systems. In this way the
likelihood of a duplicate request number generated by requests from the secondary systems
is minimal, so audit records are less confusing.
Each copy of Implementer and the Implementer Receiver should use a unique prefix for
internal work libraries to ensure an overlap does not occur. Specify a unique two-character
prefix in the data area IMPRFX in the product library of each copy of Implementer. For
details, see “Implementer Data Areas and User Exit Programs” on page 401.
You should also carefully consider the user profile names you use. To eliminate any
confusion of where a check out occurs, MKS recommends you use different user profile
names on the different systems.
191