MKS Implementer 2006 Administration Guide

Object Name Rules
The object codes allow you to use a single request to promote to one or more libraries or
systems and retain or replace specific data area values as needed. This is useful, for example,
for a data area that controls the next order number when a new customer needs the data area
value set to a newly distributed value, and an existing customer needs to retain the existing
value.
The object codes for setting a data area value are as follows:
Use object code DTAARA to copy data in the From library to the target library. It has no
special requirements.
Use object code DTAARAR to retain the existing value of a data area in the target library.
It has an the object type *DTAARA and the special characteristic *DTA. The special
characteristic is significant—it controls whether the existing data area value is retained.
You must define the DTAARAR object code with the *DTA special characteristic to
function as described.
Common Questions
Why are object codes necessary? Can’t objects just be compiled into production libraries?
Object codes allow you to consistently and accurately control how Implementer creates
objects and updates your production libraries.
Is the creation sequence critical?
Yes. The creation sequence determines the compilation order. For example, the PF object code
should have a lower sequence than the LF object code to allow compiling the physical file
before the logical file.
Object Name Rules
Implementer supports the use of rules to control the naming construct of new member/
objects. This allows an administrator to enforce a standard set of naming rules that
developers must follow when creating member/objects in check out.
Object name rules allow for flexibility in member/object naming, and provide for multiple
true conditions using standard Boolean logic. This feature also supports the ability to call
user exit programs.
Name validation is performed on an environment and object code basis, where each
positional group of the object name validates to a position and sequence in the rules
database. If more than one rule exists for a specific position, each rule must have a unique
sequence number. Any additional rules defined after the first rule for a specific position must
specify *AND or *OR to indicate a complex condition.
137