MKS Implementer 2006 Administration Guide

Integration With Local Promotions
Implementer Receiver
A powerful feature in the architecture of Implementer is the seamless support for remote
distributions. This means you define environments to Implementer and designate whether
the environments are located on local or remote systems (a remote environment must have a
remote system name specified in the environment definition).
Promotions to local and remote systems occur for an environment based on the environment
description; thus, Implementer’s distribution features are able to share features with the local
promotions. For example, to distribute a change you create a promotion request, compile the
request, and perform the Move Requests function to distribute the change. This is basically
the same process used to promote to a local environment, meaning you only need to learn
one mechanism for both local and remote promotions. The process supports a single
promotion request promoting members/objects to both local and remote libraries, either by
manually selecting multiple environments, or by using the environment group feature.
Remote System Inventory
Implementer maintains a complete inventory of the members and objects distributed to each
remote environment. This information is available on many inquiry panels and reports on the
host system, and includes the following information:
date and time a member/object was promoted to the remote system
assigned project (if using projects)
promotion request details
After initially setting up Implementer, you must run the Build List function to analyze the
members/objects in remote environments and load the inventory into the Implementer
repository on the host system. For details, see “Environment Repository Build” on page 117.
If needed, the Reset Authorities function allows you to set the object owners and authorities
on the remote system as defined for the environment. For details, see “Resetting Authorities”
on page 372.
Remote Source Members
You can specify that source is stored on the remote system for an environment. For example,
you can store source on the remote system for infrequently modified applications when you
do not retain source on the development system, or use it to secure source on a different
system.
Remote source members can be checked out from the remote system and optionally compiled
during promotion on the remote system. This applies to source members that have related
objects, such as source members for files and programs. Implementer recognizes source-only
163