02.05.2013 Views

MKS Implementer 2006 Administration Guide

MKS Implementer 2006 Administration Guide

MKS Implementer 2006 Administration Guide

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

Chapter 4: Remote Distribution Concepts and Setup<br />

190<br />

This feature is useful when you have related development activities spread across multiple<br />

systems, or a development system and a distribution system centrally located with<br />

distribution to many remote systems. You accomplish this with DDM (Distributed Data<br />

Management).<br />

Before using this feature you need to decide which system has the primary version of<br />

<strong>Implementer</strong>. This should be the system <strong>Implementer</strong> is most heavily used on.<br />

You must set the default user profile on the communications entry to have *ALL rights to the<br />

<strong>Implementer</strong> database files on the primary system. By default, DDM jobs run from the<br />

remote system under user profile QUSER and require access to the <strong>Implementer</strong> files. For<br />

details on the communications entry, see the <strong>MKS</strong> <strong>Implementer</strong> <strong>2006</strong> Installation <strong>Guide</strong>.<br />

Starting and Ending Remote Database Support<br />

A secondary system is prepared for multiple system development by using the Start Remote<br />

Database (STRRMTDB) command. This command changes the <strong>Implementer</strong> database files<br />

(PFs and LFs) to DDM files. You can convert all files or functional subsets (for example, only<br />

lock and conflict processing). An example of the command is:<br />

STRRMTDB RMTLOCNAME(remote_location_name)<br />

RMTPRDLIB(remote <strong>Implementer</strong> library)<br />

MODE(IMPMODD)<br />

LCLLOCNAME(*LOC)<br />

RMTNETID(*LOC)<br />

FILESCVT(*ALL) JOBQ(*PRODUCT)<br />

Specify the location name of the remote system and the name of the <strong>Implementer</strong> library on<br />

that system. If the mode description, local location name, or remote network ID do not match<br />

the defaults, specify the correct values. Prompt the command to show valid values for these<br />

parameters. The default converts all <strong>Implementer</strong> files to remote databases. Alternatively,<br />

you can specify *LOCKS and/or *PROJECTS. For further information, see “Performance<br />

Considerations” on page 191.<br />

After you validate the connection to the remote system (for example, remote location name,<br />

mode, local location name, and remote net ID are valid), a batch job submits to the JOBQ<br />

specified to perform the conversion. The <strong>Implementer</strong> files on the local system should not be<br />

in use when this job runs.<br />

When you no longer need to use this feature, use the End Remote Database (ENDRMTDB)<br />

command to change the DDM files on the secondary system back to physical and logical files.<br />

Once you issue this command, the <strong>Implementer</strong> database files contain the original<br />

information as before the initial Start Remote Database command was issued.<br />

You must install <strong>Implementer</strong> on the host system and the <strong>Implementer</strong> Receiver on each<br />

remote system used for development or that receives changes from the host system.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!