Detailed Aldon PDF

Aldon LM(i) Daily Operations Reference
Daily Operations Reference

DO
Aldon Lifecycle Manager

(System i Edition)
Aldon LM(i) Daily Operations

Reference
Version 7.5
Copyright 1994-2007 by Aldon. All rights reserved.

The information contained in this manual is subject to change without notice and does not
represent a commitment on the part of Aldon.
Aldon makes no warranty of any kind with regard to this material, including, but not limited to,
the implied warranties of merchantability and fitness for a particular purpose.
Aldon shall not be liable for errors contained in this manual or for incidental or consequential
damages in connection with the furnishing, performance or use of this material.
Trademarks and Registered Trademarks
Aldon, Aldon Lifecycle Manager, Aldon Deployment Manager, Aldon Community Manager,
Aldon LM, Aldon LM(e), Aldon LM(i), Aldon DM, Aldon CM, Aldon LM(i) Requester
Module, Aldon Workbench, Analyzer, Harmonizer Plus, and S/Compare-Harmonizer are
trademarks of Aldon.
Adobe, and Acrobat are trademarks of Adobe Systems Incorporated.
Pentium and Intel are registered trademarks of Intel Corporation.
400, DB2, IBM, ILE, Integrated Language Environment, System i, OS/400, SQL/400, and
VisualAge are trademarks of International Business Machines Corporation.
Microsoft, Windows, Visual C++, and Windows NT are registered trademarks of Microsoft
Corporation.
Java is a trademark of Sun Microsystems, Inc.
All other brand or product names are trademarks or registered trademarks of their respective
companies or organizations.
Aldon
6001 Shellmound Avenue #600
Emeryville, CA 94608-1901
Phone: +1-510-839-3535 (US), 44-1932-355711 (UK)
Fax: +1-413-751-4273
Email: info@aldon.com
World Wide Web: www.aldon.com
Updated: August 8, 2007

Product version: 7.5

Daily Operations
DO
Daily Operations Reference

Contents
Preface
Chapter 1
Overview of Aldon Lifecycle Manager (System i Edition)
DO vii
DO 1-1
Introduction ........................................................................................................DO 1-1

Applications and Releases ..................................................................................DO 1-2
Aldon LM(i) Release Environments ..................................................................DO 1-3
Development Environment ...................................................................DO 1-3
Integration Environment .......................................................................DO 1-4
Quality Assurance .................................................................................DO 1-4
Production .............................................................................................DO 1-4
Archive ..................................................................................................DO 1-4
Objects ................................................................................................................DO 1-5
Types of Objects ....................................................................................DO 1-5
Identifying Objects ................................................................................DO 1-5
Object Movement ...............................................................................................DO 1-6
Access to Object Movement .................................................................DO 1-6
Checkout ................................................................................................DO 1-7
Promoting ..............................................................................................DO 1-7
Conflict Records ....................................................................................DO 1-7
Object Deployment ...............................................................................DO 1-8
Emergency Checkout and Promotion ....................................................DO 1-8
Archiving ............................................................................................................DO 1-8
Task Tracking System ........................................................................................DO 1-9
Accessing Aldon Community Manager .............................................................DO 1-9
Aldon LM(i) Works with Multiple Releases ......................................................DO 1-9
Object Version Numbers ..................................................................................DO 1-11
Object Referencing ...........................................................................................DO 1-12
Object Creation .................................................................................................DO 1-12
Object Ownership and Authorities ...................................................................DO 1-13
Verify ................................................................................................................DO 1-14
Aldon LM(i) Users ...........................................................................................DO 1-14
User Interfaces ..................................................................................................DO 1-16
Contents DO i
Chapter 2
Using Aldon Lifecycle Manager (System i Edition)
DO 2-1
Introduction to Using Aldon LM(i) ................................................................... DO 2-1

Starting Aldon LM(i) ......................................................................................... DO 2-1
Aldon LM(i) Main Menu ................................................................................... DO 2-2
Global View ....................................................................................................... DO 2-3
Global User Defaults ............................................................................ DO 2-3
Panel Specific Subsetting ...................................................................... DO 2-5
Hot Keys ............................................................................................ DO 2-5
Work with... Panels ........................................................................................ DO 2-5
Working with Release Objects ........................................................................... DO 2-6
Options Available on the Work with Objects by Release Panel ........... DO 2-9
Subsetting a Work with Panel ......................................................... DO 2-15
Chapter 3
Moving Objects
DO 3-1
Checking Out Objects ........................................................................................ DO 3-2

Overview ............................................................................................... DO 3-2
Eligible Objects ..................................................................................... DO 3-3
Eligible Recipients ................................................................................ DO 3-3
Eligible Agents: Authority to Request or Perform Checkouts ............. DO 3-3
Object Flow ........................................................................................... DO 3-4
Ownership and Authority ...................................................................... DO 3-5
Check Out With or Without Requests .................................................. DO 3-5
Check Out With or Without Task Association ..................................... DO 3-6
Selecting Additional Dependent Objects .............................................. DO 3-6
Available Interfaces .............................................................................. DO 3-6
Checking out Objects ............................................................................ DO 3-8
Transferring Objects Between Developers ........................................... DO 3-9
Emergency Checkouts .......................................................................... DO 3-9
Checking Out Files for a Child Release .............................................. DO 3-10
Promoting Objects ........................................................................................... DO 3-10
Eligible objects ................................................................................... DO 3-10
Eligible Agents: Authority to Request or Perform Promotes ............. DO 3-11
Object Flow ......................................................................................... DO 3-12
Session Protection ............................................................................... DO 3-12
Creating vs. Moving ........................................................................... DO 3-12
Creating on Promotion ........................................................................ DO 3-13
Moving on Promotion ......................................................................... DO 3-14
Level Checks ....................................................................................... DO 3-14
Dependent Objects .............................................................................. DO 3-14
Ownership and Authorities ................................................................. DO 3-15
Physical Files and Tables .................................................................... DO 3-15
Logical Files ....................................................................................... DO 3-16
Handling Data on Promotion .............................................................. DO 3-16
Deploying on Promote ........................................................................ DO 3-16
DO ii Contents
Third Party Cross Referencing Files Update on Promotion to Production .DO

3-17
Promotion With or Without Requests .................................................DO 3-17
Available Interfaces .............................................................................DO 3-17
Creating Promotion Requests ..............................................................DO 3-18
Promoting Objects ...............................................................................DO 3-18
Emergency Checkout and Promotion ...............................................................DO 3-18
Moving Objects to a Parent Release .................................................................DO 3-19
Capabilities and Features of the Promote to Parent Function .............DO 3-19
Effects of Promote to Parent ...............................................................DO 3-19
Merging Objects into a Parent Release ............................................................DO 3-25
Selecting Objects to Merge .................................................................DO 3-26
Task/Release Connections Made Automatically .................................DO 3-26
Merging Produces Multiple Log Entries .............................................DO 3-26
Merging Does Not Change Object Version Numbers .........................DO 3-26
Merge Objects into Parent vs. Promote to Parent ...............................DO 3-26
Installing Live ...................................................................................................DO 3-29
Additional Install Live Features ..........................................................DO 3-29
Changing Install Live Default Values .................................................DO 3-30
Requesting Install Live ........................................................................DO 3-34
Objects Not Yet Eligible .....................................................................DO 3-34
Objects Ineligible Due to Library Groups ...........................................DO 3-34
Fulfilling Install Live Requests ...........................................................DO 3-36
Clearing Invalid Install Live Request Conditions ...............................DO 3-37
Changing an Objects Production Location .....................................................DO 3-38
Move/Define Object Function .............................................................DO 3-38
Modifying and Testing ILE Objects .................................................................DO 3-44
Modifying and Testing ILE Modules ..................................................DO 3-44
Modifying and Testing ILE Programs ................................................DO 3-44
Retiring Objects ...................................................................................DO 3-44
Cancelling Checkouts and Deleting Objects ....................................................DO 3-45
Deleting Archived Objects ...............................................................................DO 3-46
Chapter 4
Working with Objects
DO 4-1
Working with Objects by Developer ..................................................................DO 4-2

Creating Objects .................................................................................................DO 4-4
Object Creation and ILE .......................................................................DO 4-8
Changing an Object Description ........................................................................DO 4-9
Associating Source with an Object .....................................................DO 4-10
Changing Object Attributes .................................................................DO 4-11
Moving to ILE .....................................................................................DO 4-11
Adding an Object ..............................................................................................DO 4-13
Single-Copy Create Specifications ...................................................................DO 4-16
Contents DO iii
Working with Object Dependencies ................................................................ DO 4-18

Completing Object Dependency Data for ILE Objects ................................... DO 4-20
Working with Binding Directories ..................................................... DO 4-21
Technical Details ................................................................................ DO 4-24
Create Command Defaults and Binding Directories .......................... DO 4-24
Other Setup Recommendations for ILE Objects ................................ DO 4-24
Using Object Dependency Data ....................................................................... DO 4-25
Overview ............................................................................................. DO 4-25
Acting upon Dependent Objects ......................................................... DO 4-26
Act upon Dependent Objects Panel .................................................... DO 4-26
Using the Development Log ............................................................................ DO 4-32
Use Subsetting to Limit Entries Displayed ......................................... DO 4-33
Development Log Action Codes ........................................................ DO 4-35
Development Log Error Codes ..........................................................DO 4--36
Object Version Numbers .................................................................... DO 4-36
Deleting Development Log Entries .................................................... DO 4-38
Chapter 5
Working with Conditions and
Conflicts
DO 5-1
What are Conflicts and Non-Conflict Conditions? ............................................ DO 5-2

Conditions Defined ............................................................................... DO 5-2
Conflicts Defined .................................................................................. DO 5-2
Working with Requests and Non-Conflict Conditions ...................................... DO 5-3
Types of Requests and Non-Conflict Conditions ................................. DO 5-5
Working with Conflicts ...................................................................................... DO 5-7
To display the Work with Conflicts panel ............................................ DO 5-7
Conflict Status ....................................................................................... DO 5-8
Common Types of Conflicts ................................................................. DO 5-9
Less Common Conflict Types ............................................................ DO 5-10
Resolving and Clearing Conflicts ....................................................... DO 5-11
Promoting Cleared Conflicts .............................................................. DO 5-11
Rules for Promoting Conflict Objects ................................................ DO 5-11
Setting Your Default Compare and Merge Method ......................................... DO 5-12
Merging With Harmonizer ............................................................................... DO 5-13
Resolving Conflicts Using Merge ....................................................... DO 5-13
Navigating The PC Merge Window ................................................... DO 5-15
Batch Merge Report ............................................................................ DO 5-16
Comparing With Harmonizer .......................................................................... DO 5-17
Selecting Objects to Compare ............................................................. DO 5-17
Navigating The PC Compare Window ............................................... DO 5-18
Batch Compare Report ........................................................................ DO 5-19
Working with the System i PCO Session ........................................................ DO 5-19
Chapter 6
DO iv Contents
Reports
DO 6-1
Overview of Reports ..........................................................................................DO 6-1

Page Headings ....................................................................................................DO 6-1
Custom Reports ..................................................................................................DO 6-2
Custom Report Example ....................................................................................DO 6-2
Checkout Report - PRTFCHKOUT ...................................................................DO 6-6
Promote/Create Object Report - PRTFPROMOT ..............................................DO 6-7
Object Data Report - PRTFPRTOBJ ..................................................................DO 6-8
Development Log Report - PRTFDSPLOG .......................................................DO 6-9
Appendix A
Pseudo-Source
DO A-1
About Pseudo-Source ........................................................................................DO A-2

Technical Details ...............................................................................................DO A-2
Appendix B
Menus as Aldon LM(i) Objects
DO B-1
Developing System i Menus with Aldon LM(i) ................................................DO B-1

Handling Menu Objects Using Non-Default Values .........................................DO B-3
Handling Menu Objects Using Pseudo-Source .................................................DO B-8
Working With Pseudo-Source Based System i Menus ......................DO B-12
Appendix C
Record Objects
DO C-1
Overview ...........................................................................................................DO C-2

*RCDS Object Limitations and Requirements .................................................DO C-3
Requirements and Limitations for the Underlying Files ......................DO C-3
Requirements and Limitations for *RCDS Objects .............................DO C-4
Defining Record Objects ...................................................................................DO C-5
Controlling *CONTAIN File Creation Options ................................................DO C-9
Working with *RCDS Objects ........................................................................DO C-11
*RCDS Objects in Multiple-Release Applications ............................DO C-12
Working with Underlying Files .......................................................................DO C-13
How Aldon LM(i) Manages the Physical and Logical Files ...........................DO C-13
Appendix D
PDM-Style User Options
DO D-1
About PDM-Style User Options ........................................................................DO D-1

Aldon Option Setup ...........................................................................................DO D-2
Aldon Option Setup for Abstract/Probe+ and Pathfinder ....................DO D-2
Aldon Option Setup for PDM ..............................................................DO D-3
Using Aldon Options .........................................................................................DO D-5
Contents DO v
Overview and General Instructions ..................................................... DO D-5

The Aldon Options ..............................................................................DO D--6
Object Selection ................................................................................... DO D-7
Processing Queued Orders ................................................................... DO D-8
Using Single-Object Options ............................................................. DO D-10
User Supplied Options .................................................................................... DO D-11
Creating User Options ....................................................................... DO D-11
Defining the Options File to Aldon LM(i) ........................................DO D--15
Using User Options in Aldon LM(i) .................................................. DO D-15
Appendix E
Interface to Abstract/Probe+ and Pathfinder
DO E-1
Appendix F
The Panel Interface
DO F-1
Introduction ........................................................................................................DO F-1

The System i Panels ...........................................................................................DO F-2
Panel Name and Title ............................................................................DO F-3
Panel Body ............................................................................................DO F-3
Function Keys .......................................................................................DO F-7
Enter Key ..............................................................................................DO F-9
Program Message Line .........................................................................DO F-9
Terminal Message Line ........................................................................DO F-9
Selection Panels .................................................................................................DO F-9
Single Selection Panels .......................................................................DO F-10
Multiple Selection Panels ...................................................................DO F-10
Option Processing for Sub-Files (Lists) ...........................................................DO F-11
PC Terminal Emulation ...................................................................................DO F-13
Appendix G
SQL Objects
DO G-1
Adding SQL Objects ......................................................................................... DO G-2

SQL Packages ................................................................................................... DO G-3
Object Text for SQL Objects ............................................................................ DO G-4
SQL Performance Improvement Suggestions ................................................... DO G-5
Daily Operations Reference Index
DO vi Contents
DO Index-1

Daily Operations
DO
Preface
DO
In the rush to meet implementation deadlines and to reduce growing data

processing backlogs, management control over the development process often
diminishes and testing and quality assurance standards are neglected.
Neglecting these standards, which are intended to protect the production
environment, inevitably leads to unexpected and costly production failures.
When a problem occurs in production, it is difficult to discover if it was
caused by new software changes and, if so, what those changes were. The
inability to track modifications and to manage the development and testing
effort can lead to other serious problems.
Source and object code get out of sync so that it is difficult to know
exactly what source code is running in production. Or, worse yet, the
source for a production object is lost.
Two programmers modify the same program simultaneously and one
unwittingly overwrites the other's changes.
Small changes that did not appear to need much testing end up causing
major production bugs.
Programmers leave unexpectedly and no one knows what modifications
they have been working on.
Aldon Lifecycle Manager (System i Edition) (Aldon LM(i)) helps to eliminate
these problems by providing an automated method for enforcing standards
and for maintaining control over the development process. By managing the
entire process of moving objects from the production environment into
development, through testing and Quality Assurance, and back into
production again, Aldon LM(i) allows you to feel confident that your
Preface DO vii
procedures are being followed and to know exactly what the status of any
object is at any time. Evaluate all or part of an application to check for
problems at any time using the verify function.
With Aldon LM(i), a programmer must check out a copy of an object to
make changes to it. Aldon LM(i) logs the checkout and ensures that no
one else can inadvertently check out the same program. When the changes
are complete, the programmer requests or performs a promotion into a
testing environment. When an object is promoted from Development, the
associated source is always moved with it and it can be recompiled in the
new environment to ensure that the source and object match. In addition,
the object is deleted from the Development environment to ensure that no
duplicate copies exist. After testing, promote the object into the next
testing stage or into production. For each application, specify to
Aldon LM(i) how many environments an object must pass through before
it is moved back into the production environment.
Once objects have been placed in the quality assurance or production
environment on your development system, they can be deployed via
SNADS or magnetic media to remote systems where they can undergo
further development or can be placed in production. Deploy automatically
on promotion into quality assurance or production, or as a separate step.
Aldon LM(i) allows you to set your standards. It enforces them. For each
application you define to Aldon LM(i), specify whether you want objects
to pass through separate testing and Quality Assurance phases. This
enables you to require more rigorous testing for critical applications. In
addition, you can authorize users to specific functions by application. For
example, you can allow programmers to check out objects, but may want
librarians or managers to promote them into testing or Quality Assurance.
Allow some users to request checkouts or promotions and others to fulfill
their requests. Since every operation is logged, it is easy to find out who
has worked with application objects and what operations they have
performed. Entry of a comment for each checkout or promotion can be
optional or required.
Development of reliable software requires testing of changes with
multiple sets of test data. The production environment may also require
multiple sets of parallel yet independent data, as when an application
processes data for several divisions of a company on a single system.
Aldon LM(i) keeps multiple data libraries in sync by automatically
updating data libraries with your latest file changes as they are developed
and promoted.
Objects in an application being changed for a common goal can be
temporarily grouped together as a task using the Task Tracking System.
Tasks help users organize changes in progress, and aid in selecting and
manipulating the objects involved. New tasks may be defined by
authorized users at any time from within common functions. Users may
DO viii Preface
inquire about an individual task's status by focusing any of the

Aldon LM(i) object displays on that task, or view task information from a
panel dedicated to working with tasks. Any number of tasks can be under
development simultaneously. Use of the Task Tracking System can be
optional or required.
For objects in production, Aldon LM(i) provides similar flexibility by
allowing you to check out and promote objects into a new release, or to
replace production objects within the original release as soon as new ones
are fully tested. If you elect to create new releases, Aldon LM(i) stores all
of the objects for a particular release in separate libraries which can be
placed ahead of the previous release libraries in production library lists.
With this method, if a problem arises in the new release, it is easy to
return to the former production release. If you group objects being
changed into tasks with the Task Tracking System, the results of several
tasks will typically be included in each release.
For extra safety, you can archive existing copies of production source
members and objects before they are replaced. You can then retrieve the
archived copies if a failure occurs.
You can name the default job queues, job descriptions, and output queues
for Aldon LM(i) for each application or release. You can also set rules for
naming the libraries that contain objects at each stage of the development
cycle or can allow specific names to be given.
Aldon LM(i) is designed to be comprehensive and easy to use. All panels
are SAA compliant and supported by context sensitive help text. The
panels offer a point and shoot orientation. Display a list of objects that
meet your criteria, then indicate to Aldon LM(i) which ones to work with
and what you want done.
Aldon LM(i) is not just a simple implementation tool or a
turnover-to-production utility. It is an integrated system to provide you
with management control of the entire software development process. Tell
Aldon LM(i) how to structure your development environment and what
your standards are. It maintains the structure and the standards and allows
you to know exactly what activity is occurring. It helps you to get more
changes and tasks into production more quickly without sacrificing
quality and reliability. It allows you to manage change.
Preface DO ix
DO x Preface

Daily Operations
DO
Chapter 1
Overview of Aldon Lifecycle
Manager (System i Edition)
Introduction
This chapter provides an overview of how Aldon Lifecycle Manager (System
i Edition) (Aldon LM(i)) manages the software development and
implementation process. It defines Aldon LM(i) concepts, and processes, and
provides examples of how to use Aldon LM(i) to perform development work.
It describes:
Grouping of programs into applications and releases
Grouping of libraries into environments for each release
Movement of objects through release environments during the
development process
Integration of multiple-release capabilities into Aldon LM(i)
Options for structuring applications, releases, and environments
Movement of source and objects from Production into Development,
through Integration and Quality Assurance, and back into Production again
within a release
Adding and populating releases to create new versions of an application
Suggested Aldon LM(i) user classes, and operations you might want
different classes of users to perform
Testing procedures for objects in various stages of development
Use of reference libraries in assigning ownership and authorities to objects
Use of the Aldon LM(i) verify function to check the integrity of release
libraries, data libraries, and deployment libraries
Overview of Aldon Lifecycle Manager (System i Edition) DO 1-1
Applications and Releases

With Aldon LM(i), related objects are defined as an application. For
example, one application may contain objects required for managing a
manufacturing operation. Another may contain objects used to manage
personnel and human resources.
Use application-level settings to instruct Aldon LM(i) whether to:
Log each action taken on application objects
Log deployment of objects to other systems
Manage production data
Archive old copies of objects
If there is a single release for an application, production objects are
replaced as soon as new copies are fully tested. If there are multiple
releases for an application, changed objects accumulate in a new set of
libraries as work on them is completed.
When development of a release is complete, you can lock the release to
prevent further modification of Production objects.
For each release you can specify:
The number of testing environments used
Library naming rules
Assignment of authorities to objects in various stages of development
and testing, and in production
Who has access to the Aldon LM(i) operations that work with objects
Object creation commands
Options governing object creation library lists
The processing environment for Aldon LM(i) operations performed on
objects in the release. This includes job queues, job descriptions, and
output queues
DO 1-2 Overview of Aldon Lifecycle Manager (System i Edition)
Aldon LM(i) Release Environments

Each Aldon LM(i) release consists of several environments. Each
environment contains objects and corresponding source at a specific stage
of the development cycle. As you move objects through each phase of the
development, testing, and implementation process, objects pass through
corresponding Aldon LM(i) environments. The different environments
each use different libraries. This structure allows developers and testing
personnel to access the appropriate copies of objects with simple library
list modifications.
Development
Integration *
Quality
Assurance *
*optional environments
Production
Archive **
**defined at application level
Figure 1 - Aldon LM(i) Environments
The following sections briefly describe each Aldon LM(i) environment.

Descriptions indicate the purpose of each environment, and which
environments are optional or shared among releases.
Development Environment
Developers use the Development environment for the creation of new
objects and for the maintenance of existing ones. Developers can also test
their changes using this environment. The Development environment is
the only environment in which source can be changed. Each developer
can have separate libraries for source and objects or they can have one
library containing both source and objects. Developers can share
development libraries if necessary. Development libraries contain objects
developers are currently working with. A developer may use the same
libraries for all releases of all applications or may have different libraries
identified for some applications or releases. A developer's libraries may
be located on a remote system connected to the host system on which
Aldon LM(i) resides. PC based development is also supported.
Integration Environment
Use the optional Integration environment when multiple developers want
to test their changes together. The Integration environment for a release
consists of either one source library and one object library or one library
containing both source and objects. Source members cannot be changed
in Integration. They must be checked out into the Development
environment for further modification if failures occur during Integration
testing. Add or remove the Integration environment of a release as
needed.
Quality Assurance
Use the optional Quality Assurance environment for final testing by
Quality Assurance personnel or for user acceptance testing. Its contents
are typically controlled by a Quality Assurance librarian. It also consists
of either one source library and one object library or one library
containing both source members and objects. Source members cannot be
changed in Quality Assurance, so they must be checked out into the
Development environment to be fixed if failures occur during Quality
Assurance testing. Add or remove the Quality Assurance environment of
a release as needed.
Production
The Production environment within a release can consist of up to 23
libraries, each of which can contain source and objects. Objects end up in
the Production environment after passing through the testing
environments. The Production environment can contain a full set of
source and objects, or it can consist of only objects and source that have
been changed for a release. If the Production environment of a release
consists of only changed objects, it is combined with the Production
environments of prior releases to form a working version of the
application.
Archive
The optional Archive environment receives copies of old objects as new
copies are moved into the Production environment. A user with Restore
from archive and Perform checkout or Perform emergency checkout
authority can restore copies of old objects from the archive to
Development.
Objects
Types of Objects
Aldon LM(i) works with objects created from source code such as
COBOL or RPG programs (including ILE programs), objects created by
CL commands such as data areas or JOBDs, and objects created by some
third party vendor packages such as PowerHouse from Cognos.
When you define a release, Aldon LM(i) creates database entries
associating source-based objects with their source code, and records other
objects as non-source objects. Both source-based and non-source
objects are available to developers for modification.
When modifying a source-based object, the developer receives the source
code associated with the object for editing. When modifying a non-source
object, the developer receives the actual object which can serve as a
model for the new replacement object.
If a non-source object is CL based (can be created by executing one or
more CL commands), the developer may create pseudo-source for it.
Pseudo-source is a CL source member containing commands that create
the object. The developer associates the pseudo-source with the object
using an Aldon LM(i) function to transform the non-source object into a
source-based object. Aldon LM(i) re-creates the object by executing the
pseudo-source when necessary. The pseudo-source is available as the
starting point for future modifications.
In this user documentation, creating an object refers to compiling
programs and program modules, binding program modules into ILE
programs, and the execution of pseudo-source to recreate CL based
objects. Source includes both standard compilable source code and
pseudo-source except where pseudo-source is specifically mentioned.
Source-based refers to both compilable language based and CL based
objects. Non-source object refers to CL based objects not associated
with pseudo-source, objects that must be created by applications, and
source-based objects for which no source is available.
Identifying Objects
Within an application, a given object-name/type combination identifies a
unique object. Several versions of each unique object which may exist,
each in a different release environment. The same object-name/type
combination may be used in more than one application, but Aldon LM(i)
does not recognize or enforce any relationship between objects in
different applications.
Object Movement
As objects move through the stages of development, they move through
corresponding Aldon LM(i) environments. Figure 2 depicts the flow of
source and objects during development. Any movement from Production,
Quality Assurance, or Integration to Development is called a checkout.
Any movement toward Production is called a promotion. A developer
checks out an object to work on it. The object is then promoted through
testing, Quality Assurance, and back into Production. Once an object
reaches Quality Assurance or Production, it can be deployed to remote
systems.
Aldon/CMS Environments and Object Movement

Checkout
Production
Production
Development
Integration*
Quality
Assurance*
Production
Promotion
* These environments optional at release setup.
Figure 2 - Object Movement Within a Release
Access to Object Movement

Before any movement operation is performed, Aldon LM(i) checks to
ensure that the requesting user is authorized to perform that operation.
You can allow some users to request a promotion or checkout operation
and others to actually perform it. If you select this option, the movement
process is separated into two steps. The first step is the creation of a
request. The second is the fulfillment of that request. For example, you
might want to allow developers to request that objects be promoted into
the Integration environment, but might want a development manager to
actually review the requests and perform the promotions. In addition, you
can restrict users from performing specific types of promotions. For

example, you may want to allow developers to promote objects into the
Integration environment, but not into Quality Assurance. Authority to
request or perform promotions or checkout operations can be granted for
the entire system or for each application.
You can require some users to create requests to check out or promote
objects and can allow others to check out and promote without requests.
In addition, you can require requests for promotions into some
environments and allow promotions into other environments without
requests.
Checkout
Aldon LM(i) provides controlled access to source code through use of a
checkout function. The checkout function ensures that only authorized
users check out source code and tracks object movement to insure that
changes are performed cumulatively rather than in parallel. Aldon LM(i)
object referencing identifies and presents related objects which may also
require checkout and modification to work with objects initially selected
for checkout.
Promoting
After completing modifications, promote an object from Development
into the next environment in use for the release (Figure 2). Continue
promoting the object forward from environment to environment as you
complete each phase of testing until the object reaches the Production
environment.
Conflict Records
Conflict records prevent hazardous object movements from taking place
without proper authority and needed integration of parallel changes. The
Aldon LM(i) object database tracks all copies of an object within an
application. Checkouts that could result in an overwrite of one set of
changes by another on promotion, create conflict condition records on
the copies of object involved. Conflict records must be removed by a user
with the proper authority before promotion of the copies. Resolve
conflicts by merging changes with Harmonizer or Harmonizer (Windows
Edition), then promote the copy of the object created by the merge.
If you are working with multiple releases of an application, changes in
one release that may be important for other releases can generate conflict
conditions in those releases.
Object Deployment
After developing and testing objects, you can deploy them using Aldon
LM(i) object deployment. Deploy them to remote locations using IBM's
Systems Network Architecture Deployment System (SNADS) or
magnetic media, or locally to libraries outside of Aldon LM(i) on the
same system. Deploy objects automatically on promotion into Quality
Assurance or Production, or initiate deployment separately.
Emergency Checkout and Promotion

Use the emergency checkout function of Aldon LM(i) to bypass the
normal development cycle when a production failure occurs. Check
source directly out of the Production environment, even if a copy of the
object exists in Development, Integration, or Quality Assurance.
Promotion moves the object directly back to the Production environment.
If a copy of the object exists in Development, Integration, or Quality
Assurance, Aldon LM(i) creates a conflict condition record to prevent
promotion of the object until the emergency changes have been integrated
with the work in progress. This prevents the inadvertent overwriting of the
emergency change when the object that was checked out with the normal
checkout function is promoted into the Production environment.
Aldon LM(i) can also invoke Harmonizer or Harmonizer (Windows
Edition) to merge the emergency changes with those made to the other
active copy of the object if necessary.
Archiving
If an application uses the archive feature of Aldon LM(i), promotion of an
object into the Production environment moves source for the prior copy of
the object to the application archive before replacing it with source for the
new copy of the object. If for any reason, the object must be retrieved, it
can be checked out into the Development environment from the Archive
library. Control the number of copies saved and whether source only, or
source and object is archived using application-level options.
Task Tracking System

Use the Aldon LM(i) Task Tracking System to group objects needed to
accomplish a goal and to associate the objects with notes describing the
task. You can move groups of objects together by specifying the task, or
you can move one object at a time. Aldon LM(i) allows you to review lists
of the objects by task, in a particular environment, or with an outstanding
check out or promotion request and to select the ones you want to move
from the lists. Every checkout or promotion is logged by Aldon LM(i) so
that you can track the history of every object and can determine the status
of any object or task at any time.
Accessing Aldon Community Manager

You can access Aldon Community Manager (CM) issues from associated
Aldon LM(i) tasks.
Community Manager allows you to link one or more CM issues to any
task in Aldon LM(i). A URL to CM, available on the Work with Tasks
panel, displays the issue(s) attached to a specific Aldon LM(i) task. For
more information about CM, see Linking to Aldon CM Issues starting
on page TT B-1 in the Aldon LM(i) Task Tracking System Reference.
Aldon LM(i) Works with Multiple Releases

For sites with relatively simple development needs, a single release of an
application may be sufficient. For sites developing or maintaining several
versions of an application simultaneously, Aldon LM(i) supports multiple
releases. Multiple-release capability is fully integrated throughout
Aldon LM(i) and is largely transparent to the user. Use the same panels to
perform development functions when working with an application with a
single release as when working with an application having many releases.
There are two types of releases in Aldon LM(i): Base releases and Delta
releases (Figure 3). A Base release contains a complete set of application
objects. A Delta release contains objects added and changed since the
prior release.
Base and Delta Releases
Base Release: BASE 1

Object A
Object B
Object C
Object D
Object E
Object F
Object G
Delta Release: DELTA 1A

Modified Object, A'
Modified Object, D'
New Object, H
Figure 3 - Aldon LM(i) Release Types
Related releases may be visualized as a tree of Delta releases descending

from a Base release. The samples in Figure 4 on page DO 1-11 illustrate
the range of valid release relationships under Aldon LM(i). The set of
releases traversed by starting at any Delta release and tracing back to the
Base form a functional version of the application. Modified objects closer
to the starting Delta replace older copies of the objects closer to the Base.
Placement of libraries in the library list in accordance with their order in
the tree structure provides the correct copy of each application object for
checkout, compilation, and running the application.
Aldon LM(i) supports an unlimited number of Base and Delta releases for
each application. For many applications, a simple release structure
consisting of a single Base release, or a Base release with one associated
Delta release is sufficient.
Conflicts may arise when changes are made to related releases.

Aldon LM(i) provides tools for tracking and resolving these conflicts.
Sample Valid Release Trees

Base 1
Base 2
Delta 1A
Delta 2A
Delta 3B
Base 5
Delta 4A
Delta 4D
Delta 3A
Delta 2B
Base 4
Delta 4B
Base 3
Delta 5A
Delta 4C
Delta 5B
Delta 5C
Delta 5D
Delta 4E Delta 4F
Figure 4 - Sample Valid Release Trees
Object Version Numbers

Each copy of each object in Aldon LM(i) bears an object version number
identifying the Production copy it originated from and the number of
times it has been checked out. Object version numbers also appear in
development log entries which provide an audit trail of all development
activity.
Object Referencing
Aldon LM(i) can gather information on object dependencies to allow easy
locating of all objects depending on a given object. Knowing where an
object is used aids in assessing the impact of changing a given copy
member, include member, file, or program. After changing an object or
completing one phase of testing, use object dependencies when
promoting the object to automatically locate and create objects needed to
work with the changed object in the new environment.
Object Creation
Aldon LM(i) automates and simplifies object creation. The create
command and options used for a given copy of an object can be:
Specified directly by editing the create options for existing copies of
the object
Allowed to default to values set for that object type and attribute by a
create command default at the release, application, or global level. At
the release and application levels you can set defaults by object name.
No prior set up is required to create objects with Aldon LM(i). Defaults
set when the product is shipped meet the needs of many sites without
modification. Aldon LM(i) ships with global-level create command
definitions for all existing IBM create commands. You can define
additional vendor or user supplied create commands to Aldon LM(i) at
the global or application level.
The command and command options to be used for a given object type
and attribute can be specified in a create command default. At the
application level, specify create command defaults for individual objects
as well as by type and attribute. Use create command defaults to direct
Aldon LM(i) to use a vendor or user supplied create command instead of
defaulting to the standard IBM command. Options for both custom and
standard IBM commands may also be specified in create command
defaults.
See Custom Object Creation Setup starting on page SA 23-1 in the
Aldon LM(i) Setup and Administration Reference for more
information.
Aldon LM(i) handles execution of the pseudo-source you provide to
create non-source objects. No special commands are needed.
The object creation function also supports creation of non-resident

objects to obtain copies required for testing. The create non-resident
function compiles an object directly into an environment where it is
required to prevent level checks. This circumvents checkout to
Development and subsequent promotion back to the desired environment.
Source never enters Development so change control is maintained.
Aldon LM(i) object referencing can identify all non-resident objects
required to test a changed object.
Object Ownership and Authorities

In order to prevent unauthorized changes to source and objects,
Aldon LM(i) maintains limits on access to the Integration, Quality
Assurance, Production, and Archive libraries and to the objects in them.
When you define a new release to Aldon LM(i) by mapping existing
libraries, Aldon LM(i) grants itself all authority to the libraries and
objects, but does not revoke any existing authorities. When you promote
objects or load them into Aldon LM(i) libraries from libraries that are not
defined to Aldon LM(i), Aldon LM(i) assigns an owner to them and
grants specific authorities.
Aldon LM(i) uses one of two methods to assign ownership and authority
to an object: Aldon LM(i) defaults or reference objects. The default
ownership and authorities assigned by Aldon LM(i) have been carefully
chosen and will meet the needs of many locations. Reference libraries and
reference objects provide an additional method of assigning ownership
and authority that is powerful, yet flexible, and allows a broad range of
control with minimum set up. Use reference objects, to assign ownership
and authorities by object name, object type, Aldon LM(i) environment,
release, or application, or by any combination of these parameters. Create
special reference libraries containing only as many dummy reference
objects as needed, or use existing libraries with live objects or older
copies of the objects that already have the correct settings. Create a
special reference library for any environment of any release, or share
reference libraries across any number of environments in any number of
releases and applications. Identify reference libraries by name, or locate
them using the library list in effect when the operation is performed.
When assigning ownership and authorities to an object, Aldon LM(i) first
checks for an applicable reference object. If Aldon LM(i) does not find a
reference object it uses default values.
Default ownerships and authorities, and the use of reference libraries and
objects are described in Ownership, Authorities, and Reference
Libraries on page CG 2-1.
Verify
Aldon LM(i) maintains a database describing the location and nature of
all application objects. Use the Aldon LM(i) verify functions at any time
to check the integrity of application libraries, data libraries, and remote
libraries that receive deployed objects. Verification checks for addition or
deletion of objects from outside of Aldon LM(i), checks object
ownerships and authorities, and identifies possible problems with
logical/physical file relationships.
For more information about Aldon LM(i) verify functions, see Verify
Functions starting on page SA 25-1 in the Aldon LM(i) Setup and
Administration Reference.
Aldon LM(i) Users

There are a number of different types of Aldon LM(i) users. In
Aldon LM(i) you can define user classes for different types of users.
Define an individual user as a member of a class or by specifying unique
authorities.
This section describes predefined user classes included with Aldon LM(i)
and the operations they might perform. If your development staff is very
large, you may have many different classes of users with authority to only
a limited number of functions. If your staff is small, you may have only a
few classes of users authorized to perform a wide variety of Aldon LM(i)
activities.
&DEVELOPER
Developers are directly responsible for maintaining existing source
members and objects, and for creating new ones. They also must be able
to test the changes they have made before promoting objects from their
development libraries. For this reason, developers usually have complete
authority to the objects in their own libraries and the ability to use the
objects in the Integration, Quality Assurance, and Production
environments.
With Aldon LM(i), you can allow developers to check out source
members and objects when they need to work with them. If you do not
want developers to be able to check out source members and objects
without approval, you can allow them to request checkouts and provide
another user with the ability to fulfill their requests. You can have a
similar arrangement with promotes. You can allow developers to promote
objects into the Integration, Quality Assurance, and Production
environments, or you can require that they submit promotion requests that
are actually fulfilled by a manager or librarian. You can also give
developers emergency checkout authority so they can quickly perform an
urgent fix without weakening the audit trail or the structure defined for
normal program development.
&LIBRARIAN
In a large development operation, you might want to assign a person the
responsibility of controlling the objects in a particular environment. This
person would have the ability to fulfill promotion or checkout requests.
Since you can grant authority to specific promotion operations, you could
have one person who fulfilled requests for promotion into Integration,
another who fulfilled promotion requests into Quality Assurance, and
another who fulfilled requests for promotion into the Production
environment. You could also assign a specific person the responsibility of
fulfilling checkout requests. Librarians or operators might also have the
ability to resolve and clear conflict conditions or deploy objects to remote
systems.
&MANAGER
If you would like managers to review checkout or promotion requests and
to actually fulfill them, you can grant them the authority to the checkout
or promotion functions. You might also want to give managers the ability
to resolve and clear any conflicts that might occur and to create or change
options, defaults, authorities, and the definitions of applications and
releases. If you choose to group application changes into tasks, managers
can be given authority to define the tasks.
&QUALITY (Quality Assurance Personnel)
Quality Assurance personnel typically perform testing activities and
control the contents of the Quality Assurance libraries. To do testing, they
require access to the objects in the Quality Assurance, and Production
environments. To control the contents of the Quality Assurance libraries,
they also need to have the ability to promote objects from Integration or
Development into Quality Assurance. In addition, you might grant them
the authority to request promotions into the Production environment or to
actually promote objects into the Production environment once they have
been thoroughly tested.
User Interfaces
The main access to Aldon LM(i) is through the panel interface. Many
functions may also be performed using commands or PDM user defined
options provided by Aldon. These Aldon provided PDM options may also
be used within Hawkeyes Pathfinder and Abstract Probe+ cross
referencing and documentation tools. PDM-style options may also be
created to perform custom actions from object lists within the
Aldon LM(i) panel interface. User exits are also available to invoke
custom user provided programs during most functions that move or create
objects.
Aldon LM(i) panels follow the Common User Access Standards defined
for the System i by IBM. The goal of these standards and of
implementation of Aldon products in accordance with them, is to provide
a single user interface across applications that is consistent, efficient, and
easy to use. A user's time and energy can then be spent in productive work
rather than in untangling and deciphering the idiosyncrasies of each
application they use.
Although the panel interface is designed to be clear and simple, users may
have questions about some features, or may want to insure they are taking
full advantage of all the interface has to offer. Appendix B: The Panel
Interface describes features important for Aldon users. Features most
important for new Aldon LM(i) users are summarized below:
Context sensitive help text is available at all times throughout Aldon's
System i applications by pressing the Help or F1 key. Context is
determined by the panel displayed and by the position of the cursor when
Help is requested. Place the cursor on or near an input field to retrieve a
description of the field's function and valid entry options.
Help text is available for input fields, fields that display information,
messages, function keys, and some other screen features. Panel level help
text, which gives an overview of the purpose of the panel and its
relationship to preceding and following panels, is also provided. To
retrieve panel level help text, position the cursor on the title line or on any
empty area of the panel, or press F2 after retrieving field level help.
Hypertext links on some help displays provide access to additional help
information. Hypertext links appear as underscored orange text. Activate
a link by placing the cursor at or on the link text and pressing the Enter
key. Press F11 on any Aldon help display to access additional information
by topic through a search index.
Input fields appear as underscores. If the list of values allowed for a field
is fixed and short, it appears to the right of the field. A + symbol after a
field indicates you can prompt for a list of allowed values with F4. Values
display on a single selection panel with each allowed value preceded by
a period. Type a slash (/) over the period preceding the desired value and
press Enter to make a selection.
When there is more information to view than will fit on one panel, More:
+ is displayed on the right side. Press Page Down (or Roll Up) to view
additional items. When More: -+ or More: - is displayed, press Page
Up (Roll Down) to return to previously viewed items.
On most panels a fully functional command line appears immediately
above the function key prompts. Any System i command may be executed
from this line. Retrieve commands executed during the current
Aldon LM(i) session by pressing F9.
Access to the IBM WRKSBMJOB command via F14 and WRKSPLF via
F18 is also provided on many panels.
This concludes the overview of Aldon LM(i). For detailed information on
set up and operations, refer to the Setup and Administration Reference,
the Daily Operations Reference, and to the help text provided within
Aldon LM(i).

Daily Operations
DO
Chapter 2
Using Aldon Lifecycle Manager
(System i Edition)
Introduction to Using Aldon LM(i)
This chapter introduces the main menu and the global view design used by
panels throughout Aldon Lifecycle Manager (System i Edition) (Aldon
LM(i)) and discusses Work with... panels for object movement and
manipulation. The Work with Objects by Release panel is discussed in detail.
Starting Aldon LM(i)

To start Aldon LM(i) from the Aldon Products Menu
Use the following steps to start Aldon LM(i) from a menu of all Aldon
products identified to the common installation library.
Prerequisite
Aldon LM(i) must be registered in the common installation library. See

The Common Installation Library, starting on page CG 8-1 for details.
1. On an System i command line, execute the following command:
STRALDPRD
The Start ALDON Products panel displays.
2. At the Start ALDON Products panel, in the Opt field by the command
STRLMI (or STRACMS), type 1 (Select) and press ENTER to display the
Aldon LM(i) main menu.
Using Aldon Lifecycle Manager (System i Edition) DO 2-1
To skip the Main Menu when starting Aldon LM(i)

Type the number of a main menu option after the STRLMI (or
STRACMS) command to by-pass the main menu and display the selected
panel. For example, to proceed directly to the Work with Objects by
Developer panel, execute the following command:
ACMSLIB/STRLMI 2
Aldon LM(i) Main Menu

CACMS
Rel 07.5
Aldon Lifecycle Manager for System i
(C) Copyright Aldon, Inc. 1989-2006.
All Rights Reserved.
Type choice, press Enter.

1.
2.
3.
4.
5.
6.
7.
8.
11.
12.
13.
14.
Work with objects by release

Work with objects by developer
Work with archive objects
Conditions menu
Work with tasks
Deployment menu
Display log
Work with verify requests
Setup menu
Work with applications
Work with releases
Work with data sets
User defaults: Rel:ALDON/ACMSDEMO/BASE Dvp:*NONE Tsk:*NONE

Command ===> __________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve
F14=WRKSBMJOB
F18=WRKSPLF
F22=More functions
Figure 5 - Aldon LM(i) Main Menu
Access the functions described in this chapter from the main menu shown
in Figure 5, or by entering the corresponding main menu option number
after STRLMI (or STRACMS) on the command line. For example, go
directly to the first menu option, the Work with Objects by Release panel,
by entering the command STRLMI 1.
The main menu provides access to all functions in Aldon LM(i). This
Daily Operations Reference discusses the following main menu
options: 1, 2, 3, 4, 5, 7, and portions of 6 and 8. Options and portions of
options not discussed in this document are discussed in the Setup and
DO 2-2 Using Aldon Lifecycle Manager (System i Edition)
Global View
Aldon LM(i) provides a global view of an organization's complete
software development effort while at the same time allowing the user to
focus, at a given time, on only the items of interest. This capability is
implemented through the use of global and panel specific subsetting
panels. Enter selection criteria on subsetting panels to limit items
displayed on other panels to the desired range.
Global User Defaults

Press F22 on the main Aldon LM(i) menu, or from most other panels
within Aldon LM(i), to display the More Functions panel shown in Figure
6.
Use the top portion of the More Functions panel to set default values for
release, application, group, developer and task. Enter default values for
any or all parameters, then press Enter to return to the previous panel.
These defaults are referenced for subsetting a Work with panel with
*USERDFT on the associated subset panel. For example, the default of
*USERDFT values shown in Figure 6, is equivalent to entering these
values on subset panels such as the Subset Objects by Release List panel
shown in Figure 9 on page DO 2-15. These user defaults are maintained
by Aldon LM(i) both during and between Aldon LM(i) sessions until
changed by the user. Separate values are maintained for each user.
In addition to their use on subsetting panels, Aldon LM(i) also uses values
entered here as defaults for completing some operational panels. For
example, Aldon LM(i) automatically enters the developer specified on the
More Functions panel as the developer to receive objects being checked
out on the Check Out Objects panel. Commands and user defined PDM
options also use the default values.
CMORFNC
Rel 07.5
More Functions
ALDONT01
Type choices, press Enter.

User defaults:
Release . . .
Application
Group . .
Developer . .
Task . . . .
Job ASP group .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BASE
ACMSDEMO
ALDON
PGMRA
*NONE
*NONE
+
+
+
+
+
*NONE,
*NONE,
+ *NONE,
*NONE,
*NONE,
*NONE,
name
name
name
name
name
name

__
1.
2.
3.
4.
5.
6.
Edit development tools

Set user-defined option file
Set operation defaults
Enter/work with user requests
Record task hours
Act upon dependent objects
11.
12.
13.
14.
15.
16.
Work with tasks

ASC's Abstract/Probe+
Hawkeye's Pathfinder
Generate SQL DDL
LANSA
Analyze object dependencies
Command ===> __________________________________________________________________

F3=Exit
F4=Prompt
F5=Refresh
F6=DSPMSG
F9=Retrieve
F12=Cancel
F14=WRKSBMJOB
F18=WRKSPLF
Figure 6 - More Functions Panel
More Functions
Use the lower portion of the More Functions panel to access editing, cross
referencing, SQL statement generation, and documentation tools for an
individuals use and to set user options customizing features of the Aldon
LM(i) panel interface.
Third Party Products
Key option 12 to access the main Abstract/Probe+ menu. Key option 13 to
retrieve the HAWKBAR menu bar. Key option 15 to work with LANSA.
You must install the corresponding third party software and define it to
Aldon LM(i) using option 11 on the Global Setup menu as discussed in
ABSTRACT/PROBE+, starting on page TI 1-1 before activating it from
this menu.
Other Options
See the section Setting Advanced User Preferences in the Aldon LM(i)
User's Guide for details on changing development tool defaults, setting
a user-defined options file, and setting operation defaults. See the section
Requesting Tasks under Additional Features in the Aldon LM(i)
User's Guide for details on entering user requests.
Panel Specific Subsetting

Global defaults specified on the More Functions panel work in
conjunction with subsetting panels specific to each Work with... panel
such as the Subset Objects by Release List panel shown on page Figure 9
on page DO 2-15. Together, global defaults and subsetting allow users to
display and work with as broad or narrow a group of items as they desire.
For further discussion and an example of subsetting see Subsetting a
Work with Panel on page DO 2-15.
Subsetting criteria entered for a specific Work with... panel are
maintained until the user exits from the panel back to the main Aldon
LM(i) menu. Criteria remain in effect while Aldon LM(i) performs
requested functions on listed items. Criteria are also preserved if other
Work with... panels are accessed via hot keys.
Hot Keys
Function keys and options on many Work with... panels allow direct
access to other Work with... panels. Select an item with the appropriate
option to display information about that item on a different Work with...
panel. Press the appropriate function key to display more than a single
object on a different Work with... panel. Return to the previous Work
with... panel by pressing F12=Cancel. The original panel re-displays in
the exact state you left it before hot keying.
Work with... Panels

Work with panels provide different views of application objects,
conditions and tasks, and provide options for performing daily operations.
With default settings, these panels display information for all releases in
all applications. Focus a Work with panel on as narrow or broad a group
of items as desired by using the default settings on the More Functions
panel and the subsetting panel specific to that Work with... panel. Move
easily between Work with... panels using function keys and options, or
by returning to the main menu and selecting a different panel.
Many options can be performed from several Work with... panels. Other
options are unique to a single panel. The various panels provide different
information about objects organized for different purposes.
Use option 1 on the main menu, to Work with Objects by Release panel
shown in Figure 7 on page DO 2-6. Use option 2 to Work with Objects by
Developer panel shown in Figure 19 on page DO 4-2. Use option 3 to
Work with Archive Objects panel. Use option 4 to work with objects with
pending checkout requests, promotion requests, conflict conditions, or
acknowledgement conditions using the Work with Requests and
Non-Conflict Conditions panel shown in Figure 33, Work with Requests
and Non-Conflict Conditions panel, on page DO 5-4. Use option 5 to
work with objects that have been grouped to organize activity towards a
defined goal using the Work with Tasks panel shown in Figure on
page TT 3-4. Use option 7 to Work with Verify Requests panel shown in
Figure 130, Work with Verify Requests panel, on page SA 25-12.
The next sections describe panels in order of first use by a new Aldon
LM(i) user starting with the Work with Objects by Release panel.
Subsetting for the Work with Objects by Release panel is described in
some detail. Subsetting for other Work with panels is similar and is
fully documented in the on-line help text. The Work with Requests and
Non-Conflict Conditions panel is also introduced.
Working with Release Objects

CWRKOBJREL
Position to
Work with Objects by Release

. . . . . . .
__________
*TOP, *BOT, starting characters
Type options, press Enter.

(*=Combined job)
2=Edit
3=Check out* 4=Delete
5=Browse source
7=Promote*
13=Request checkout*
14=Create* 17=Request promote* 30=Display log...
More:
+
Opt Object
Type
Attribute D Release Envs Rl T Cnds
E Chkout Dvp.
ACTGLL
*FILE
LF
K AC/BAS D QP
O
ACTGLP
*FILE
PF
K AC/BAS
IQP
COMMENTRY
*PGM
CBL
AC/BAS
P
COMMIO
*PGM
CBL
AC/BAS
I P
COMMPRT
*PGM
CBL
AC/BAS
P
RCVPRT
*PGM
RPG
AC/BAS
P
TEST
*PGM
RPG
AC/BAS *
ADA
Subset Rel:ALDON/ACMSDEMO/BASE
Command ===> _________________________________________________________________
F3=Exit
F4=Prompt
F5=Refresh
F6=Add object
F10=View 3
F11=View 2
F13=Repeat F19=Work with tasks
F23=More options F24=More keys
Figure 7 - Work with Objects by Release, View 1 of 3
Select option 1 from the main menu to display the Work with Objects by
Release panel shown in Figure 7 and Figure 8. With default subsetting,
this panel lists all objects associated with the user defaults setting from
the More Functions panel. Each object is listed once for each release
containing it.
In both views of the panel, entries include the object name, type, and
release. View 1, shown in Figure 7, also includes object attribute, and
flags indicating the data option (D), environments (Envs) and related
releases (Rl) containing copies. Columns also list the deployment status
of the object (T), pending conditions (Cnds), emergency checkout status
(E), and a checkout developer name (Chkout dvp.)
The data option column (D) displays a single letter abbreviation for
objects that have the Change object data option set to Y (Yes). K indicates
Keep destination data, a blank indicates Promote data, and a * indicates
there are multiple data options between environments.
The environments column (Envs) displays a single letter abbreviation for
each environment containing a copy of the object.
D - Development
I - Integration
Q - Quality Assurance
P - Production
* - Retired object
It is possible for copies of an object to exist simultaneously in multiple
environments. For example, if an object is in the Production environment,
and is checked out by a developer, the record displays D P to show that
copies of the object exist in both Development and Production.
If a record includes some copies selected by the current subset criteria,
and other copies not selected, letters representing copies not selected
appear in lower case. For example, if the object in the example above is
checked out for a task, and membership in that task is specified as a subset
criterion, D p is displayed because the Production copy is not
associated with the task. Lower case display informs the user that while a
Production copy exists, it will not be affected by any options selected.
The Rl column is used in applications with multiple releases. A minus
sign (-) indicates the Production environment of an ancestor release also
contains a copy of the object. A plus sign (+) indicates a descendant
release Production environment also contains a copy. A letter P in the
Rl column indicates that the release specified in the object record (the
local release) does not contain a Production copy of the object so the
Production copy of an ancestor release will be used for Production
purposes. A minus appears if the local release does contain a Production
copy. In this case the local copy is used in place of the ancestral copy of
the object.
The T (Targets) column displays the deployment status for each object, if
the Show Deployment status field has been selected on the Specify Target
Definition panel. This specification is effective for all targets (locations)
defined to the target definition. For more information about the Show
Deployment status field, see Maintaining Target Definitions starting on
page DS 5-6 in the Aldon LM(i) Object Deployment Reference. The T
column shows the following values:
Outstanding deployment status - When an object is selected for
installation at a eligible target, it is given an 'O' status. An
eligible target is a target with Show deployment status on object
displays option selected as Y (Yes). An outstanding deployment
exists from the time an installation job is submitted through to
successful installation.
Deployment failure status - If the installation job fails, the object is
given an 'F' status.
(blank) - Not participating or not in any install status.
In the conditions column (Cnds), A indicates an acknowledgement
condition, C indicates a conflict condition, and R indicates a pending
request for checkout or promotion of the object. In the emergency
checkout column (E), Y indicates the object is currently checked out
using the emergency checkout function. The checkout developer column
(Chkout dvp.) displays the name of a developer to whom the object is
currently checked out. The other developer column (Other dvp) is
described in the following paragraph.
View 2, shown in Figure 8, provides the full release name, the level of
the release (Lvl), and an other developer name. The level of a release is
a number indicating how many ancestors a release has. A Base release has
no ancestors and may be thought of as level 0. A Delta release with the
Base release as parent is a level 1 release because it has one release, the
Base, as an ancestor. A Delta release with a level 1 Delta as parent is a
level 2 release. Other dvp. indicates the developer to which a copy now
in Integration or Quality Assurance was checked out to. If there are copies
in each of these environments, each checked out to a different developer,
*MULT-n appears where n is a number indicating the number of
developers to whom the object is checked out.
CWRKOBJREL
Position to
Work with Objects by Release

. . . . . . .
__________

6=Print source
8=Display attributes
15=Change create options
19=AltEdit
Opt
__
__
__
__
__
Object
CLNADR
CLNADRL
DEMOCBL1
DEMOCBL2
DEMOCBL3
Type
*FILE
*FILE
*PGM
*PGM
*PGM
(*=Combined job)
12=Work with conflicts
28=Work with conditions ...
More:
+
Release
Lvl
Other dvp.
ALDON/ACMSDEMO/BASE
BASE
ALDON/ACMSDEMO/BASE
BASE MARKE
ALDON/ACMSDEMO/BASE
BASE MARKE
ALDON/ACMSDEMO/BASE
BASE
ALDON/ACMSDEMO/BASE
BASE
Subset: Rel:ALDON/ACMSDEMO/BASE
Command ===> _________________________________________________________________
F7=Add task
F9=Retrieve
F12=Cancel
F14=WRKSBMJOB
F17=Subset
F18=WRKSPLF
F20=Work with conditions
F21=Print
F24=More keys
Figure 8 - Work with Objects by Release, View 2 of 3
View 3, not shown, displays descriptive text associated with each object.
The object list on the Work with Objects by Release panel is sorted by
object name. Move through the list by using the Page Up (Roll Down) and
Page Down (Roll Up) keys, or type an entry in the Position to field to
move to a particular entry without paging through the list.
Initiate any of several operations from this panel. Type an entry in the
option field for a particular object to perform the indicated action on that
object.
Options Available on the Work with Objects by

Release Panel
* (after an option description)
See Option Processing for Sub-Files (Lists) on page DO F-11 for
information on *=Combined job options and the processing of multiple
non-combined job options as a group.
2=Edit
Edit source for the object using the primary editor specified for the
selected object. Control the editor used through development tool
definitions and development tool usage defaults. Use option 1 on the
More Functions panel to set user-level editing and browsing defaults.
3=Check out
Copy the object to a developer for modification using the Check Out
Objects panel.
4=Delete
Delete one or more copies of the object from the release using the
confirmation panels discussed in Cancelling Checkouts and Deleting
Objects, starting on page DO 3-45. A confirmation panel displays. You
must have Perform promotion to... authority to the environment
containing the copy to be deleted.
Warning
This option can be used to delete all copies of the object (including
archived copies).
5=Browse source
Browse objects using the browse tool specified for the selected object.
Control the browse tool used through development tool definitions and
development tool usage defaults. Use option 1 on the More Functions
panel to set user-level editing and browsing defaults.
6=Print source
Print source for the object
7=Promote*
Promote the object forward to the next environment using the Promote
Objects panel.
Display the description of the object as registered in the Aldon LM(i)
database.
9=Move/Define
Move an object to a different library group, or an object's source to a
different library group, source file, or source member. For moving groups
of objects, see 29=Move/Define (library groups)* below.
10=Specify data conversion
Specify data conversion options for moving data in a data library or
Production library into a changed physical file. See To specify data
conversion options in advance, starting on page CG 3-35 for more
information.
11=Print attributes
Print a description of the objects status in the release including
environments and libraries containing copies, tasks with which it is
associated, and deployment sets with which it is associated.

View all conflicts pending for that object on the Work with Conflicts
panel.
Create a request for checkout for the object using the Request Checkout
panel.
14=Create*
Create the object in place using the Create Objects panel.
Change the Aldon LM(i) database records controlling how the object is
created using the Change Object Creation Options panel.
16=Change
Use the Change Checked Out Object panel to change the description of an
object in Development in the Aldon LM(i) object database.
You can:
Assign an attribute such as RPT, SQLCBL, or PLI38 to an object
Change the extended attribute of an object to indicate whether or not it
uses the ILE program model.
Specify the existence of and location of pseudo-source for a
non-source object
Change the data option of an object
17=Request promote*
Create a request for promotion for the object using the Request Promote
panel.
18=Work with tasks
Displays tasks associated with the selected object on the Work with Tasks
panel.
19=Alternate edit
Edit source for the object using the secondary editor specified for the
selected object. Control the editor used through development tool
definitions and development tool usage defaults.
20=Scan for requisite objects*
Scan an object to identify the other objects it requires for its creation and
functioning. Options 41 and 42 read this information from the Aldon
LM(i) database to locate all objects dependent on a selected object.
23=Check out (emergency)*

Copy the object from Production to a developer for emergency
modification.
24=Work with archive
Display information about archived copies of the object on the Work with
Archive Objects panel.
25=Retire
Retire object flags an object as deleted so that, as it is promoted or
deployed, the target object is made inaccessible. When an object is
retired, any other version of the object existing in a later environment or
an ancestor release becomes invisible during execution.
27=Promote to parent*
Promote an object from a child or Delta release to its parent or ancestor
release. See To promote individual objects to parent, starting on page
DO 3-21 for more information.
28=Work with conditions
Display requests and conditions pending for the selected object on the
Work with Requests and Non-Conflict Conditions panel.
29=Move/Define (library groups)*
Change the object and source library group assignments for a group of
objects. See also 9=Move/Define above.
30=Display log
Display development log entries for the object using the Display
Development Log panel.
32=Change create overrides
Object create overrides specify for individual objects, what overrides are
to be applied prior to executing the create command for the object.
35=Compare
Compare two different copies of an object using Aldons Harmonizer or
Harmonizer (Windows Edition) comparison utility. You must have an
installed copy of Harmonizer or Harmonizer (Windows Edition) defined
to Aldon LM(i) to use this option.
37=Request promote to parent*
Request promote an object from a child or Delta release to its parent or
ancestor release.
39=Display requisite objects

Display a list of objects required by the selected object for creation or
functioning on the Display Requisite Objects panel. The displayed objects
are requisites of the selected object.
40=Define requisite objects
Manually specify additional objects as requisites of the selected object
using the User-Defined Requisite Objects panel.
41=Act upon dependent objects
Locate objects which depend on the selected object for creation or
functioning. Once identified, dependent objects may be acted on using all
available options. If several objects are selected together with this option,
the dependent objects for each appear on separate panels.
42=Act upon dependent objects*
Locate objects which depend on the selected object for creation or
functioning. Once identified, dependent objects may be acted on using all
available options.
44=Work with deployment sets
Displays the Work with Deployment sets panel.
45=Assign binding directories
Work with binding directory/program associations for a binding directory
or ILE program using the Work with Binding Directories panel.
47=Install live*
Copy the object from Aldon LM(i) test or Production libraries to
additional libraries for testing or Production use. Install live can copy the
object to additional libraries locally on the host system or to libraries on
one or more remote systems. Install live provides a way to group objects
so that they are installed as a unit. Any failure causes the entire group of
changes to be backed out.
48=Deploy*
The Work with Deployment sets panel displays if objects of more than
one release are selected. The Select Environments for Deploy Objects
panel displays if deployment profiles are defined for more than one
environment for each selected release.
50=Merge into parent*
Merge an object from the production environment of a child release to the
production environment of the parent release. For more information, see
Merging Objects into a Parent Release on page DO 3-25.
57=Request install live*

Create a request for install live of an object.
99=Display LM(i) blocking where used...
Use of this option on an object of the release results in a list of all objects
defined to LM(i) that use the selected object as a blocking object or
source. For more information, see Overview of Blocking Objects and
Source starting on page UG 5-17 in the Aldon LM(i) Users Guide.
XX (User defined PDM-Style options)
This panel supports use of PDM-Style options created by the user and
defined to Aldon LM(i).
If you opted not to use requests for checkouts or promotions, use option 3
or 7 from this panel to check out or promote objects. If you opted to
require checkout or promotion requests, create the requests from this
panel with options 13 and 17. To fulfill those requests, use the Work with
Tasks panel, the Work with Requests and Non-Conflict Conditions panel,
or, for promotions, the work with Developer Objects panel. Use option 12
to access the Work with Requests and Non-Conflict Conditions panel for
a specific object.
You can require some users to create requests to check out or promote an
object and allow others to check out and promote without requests. You
can require requests for promotions into some environments and allow
promotions into other environments without requests. Request
requirements never apply to emergency checkouts which are controlled
with a separate authorization. See the Defining Users, starting on page
SA 3-1 for more information on request requirements.
General purpose function keys are described in Appendix B: The Panel
Interface. Descriptions of function keys available on the Work with
Objects by Release panel that are unique to this panel or to Aldon LM(i)
are described below.
F6=Add Object
Add an object not previously defined to the application to this release using the
Add Release Object panel shown in Figure 41 on page UG 5-4.
F7=Add Task
Define a new task for organizing development work using the Define Task panel
shown in Figure 32 on page UG 3-8. Access this function by pressing F6 on the
Work with Tasks panel.
F17=Subset
Subset the Work with Objects by Release panel using the Subset Objects by
Release panels shown in Figure 9 on page DO 2-15 and Figure 10 on
page DO 2-17.
F19=Work with tasks

Hot key to the Work with Tasks panel shown in Figure 36 on page UG 3-13.
F20=Conditions menu
Hot key to the Work with Requests and Non-Conflict Conditions panel shown
in Figure 27 on page UG 2-52.
F21=Print
Print the currently selected list of object records as a report using a confirmation
panel similar to the panel shown in Figure 43, Confirm Print of List Panel, on
page DO 6-3.
Subsetting a Work with Panel

To limit the object entries displayed on the Work with Objects by Release
panel, press F17 to work with the Subset Objects by Release List panels
shown in Figure 9 on page DO 2-15 and Figure 10 on page DO 2-17.
Use these panels to select object records for display on the previous panel.
Set selection criteria as desired and press Enter. The previous panel
displays with only those records meeting all selection criteria.
Press PAGE DOWN to display the second page of the Subset Objects by
Release List panel.
CSBSOBJREL
Subset Objects by Release List

In environment . . . . .
Select as true for . .
Developer designation. .
*NA
1
*NA
Included in task . . . .
*NA
Residence status . . . .
Object . . . . . . . . .
1
*ALL
Object type . . . . . .
*ALL
+
Object attribute . . . .
*NA
Release . . . . . . . .
*USERDFT
Application . . . . .
*USERDFT
Group . . . . . . .
*USERDFT
Release view . . . . . .
*STD
*PARLENV environment
User defaults: Rel:ALDON/DEMOAPP/BASE1
F3=Exit
F4=Prompt
F5=Refresh
*NA, *ACT, D/I/Q/P

1=Any copy, 2=Every copy
+ *NA, *USERDFT, *NAMED, *CRTNONRES,
name
+ *NA, *USERDFT, *ANY, *NOT,
generic*, name
1=All, 2=Res only, 3=Non-res only
*ALL, generic*, name

*ALL, type
+ *NA, generic*, name, *BLANK
+ *USERDFT, *ALL, generic*, name
*STD, *EXPAND, *PARLENV, *SHARED
DVP, ITG, QUA
Dvp:*NONE Tsk:*NONE
F12=Cancel
F22=More functions
Figure 9 - Subset Objects by Release List, View 1 of 2
The Select as true for field modifies the meaning of the In environment
parameter specified on the line above. Specify 1 to include a record in the
display if any copies of the object in a release are present in the selected
environment(s). Specify 2 to require that all copies of the object in a
release be present in the selected environment(s).
Example:
Object DEMOCBL1 is present in a release in the Quality Assurance
and Production environments. Set In environment to P.
Enter a 1 for Select as to include the record because a copy is
present in Production.
Enter a 2 for Select as to exclude the record because a copy exists
outside of Production (the object also exists in Quality Assurance).
Set *USERDFT values for task, developer, release, application, and group
by pressing F22=More functions.
In the Residence status field, select one of the following:
1 = All Creates both non-resident and resident objects
2 = Res only Creates only resident objects
3 = Non res only Creates only non-resident objects
The Release view field controls whether or not records display for
ancestors of a release that contain earlier versions of the same objects or
contribute production copies of objects not contained in production
libraries of a local release.
When release view is set to *PARLENV, the *PARLENV environment
field must also be filled in.
*PARLENV (parallel environments) setting causes the RL (Related
Releases) column to show the environment letter (I, Q, or P) of the
ancestor copy to be used for creates, install live, and deployment, if there
is not a copy of the object in the production environment of the selected
release. The purpose of the view is informational and allows selection for
install live.
When the subset is in effect, only options 8 (Display attributes), 30
(Display log), 47 (Install live), and 57 R(equest Install Live) are available.
This view can only be selected when subset to a single release and only
shows test environment letters if the selected release (or one of its
ancestors) has the option Include parallel environments of parent release
for creates set to Y (Yes).
You cannot change your user default release when this subset view is
active.
You must specify a *PARLENV environment of either DEV, ITG, or
QUA that is to be used to decide the environment of the parent copy.
Objects that are not normally visible may appear in the list, as in the
following example:
BASE release
DELTA1 release (include parallel environments of parent)

DELTA2 release (not include parallel environments of parent)
If the list is subset to DELTA2 release, release view set to *PARLENV,
and *PARLENV environment set to ITG, then object X, that exists only in
ITG of BASE appears in the list. From the standpoint of DELTA2, object
X does not exist.
If the *PARLENV environment is set to DVP then X appears, but if
*PARLENV environment is set to QUA, then X would not appear because
the ITG environment is not included when compiling or deploying from
the QUA environment.
The Display Attributes function (option 8) shows the same parent
production copy as shown on the list when requested from the
*PARLENV view. If this is not PDN, a special note is made.
For more information about parallel environments of parent release, see
Parallel Environments of Parent Releases starting on page CG 1-6 in
the Aldon LM(i) General Topics Reference.
At the second page of the Subset Objects by Release List panel, enter the
desired criteria.
CSBSOBJREL
Subset Objects by Release List

More: Has condition category
Include retired objects
Retired as seen from
environment . . .
Library group: Object
Source
*NA
*NA
*ANY
*NA
*NA +
*NA, *ANY, *NOT, A/C/F/H/R

*NA, *NO, *ONLY
*ANY, DVP, ITG, QUA, PDN
+ *NA, *UNDEFINED, *ANY, library group
*NA, library group
F3=Exit
F4=Prompt
F5=Refresh
F12=Cancel
F22=More functions
Figure 10 - Subset Objects by Release List, View 2 of 2
The Include retired objects field specifies whether retired objects are to
be included in the resulting list.
*NA Include all retired objects in the subset it they meet the other
selection criteria
*NO Exclude all retired objects from the list
*ONLY Only show retired objects in the subset list
The Retired as seen from environment field qualifies the Include retired
object selection by defining what environment you want the retired
objects to apply to:
*ANY
DVP
ITG
QUA
PDN
For example, if the object has been checked out and retired, but the retire
has only been promoted as far as QUA then the object would be seen as
retired if you are viewing from the *ANY, DVP, ITG, or QUA, but if you
are viewing from PDN, it does not show as retired.
In the Library group field, you can subset by object, source, or both.
Enter the library group number 01 to 99. If you are already requesting a
subset to a single release, press F4 (Prompt) to select a library group from
a list.

Daily Operations
DO
Chapter 3
Moving Objects
This chapter provides detailed conceptual overviews and discusses functions,

options, rules, and requirements for object movement in Aldon Lifecycle
Manager for System i (Aldon LM(i)). This chapter also describes how to work
with less commonly used functions. See the User's Guide for a basic
conceptual overview and step-by-step instructions for more commonly used
object movement functions.
This chapter includes the following topics:
Checking Out Objects, starting on page DO 3-2
Promoting Objects, starting on page DO 3-10
Emergency Checkout and Promotion, starting on page DO 3-18
Moving Objects to a Parent Release, starting on page DO 3-19
Merging Objects into a Parent Release, starting on page DO 3-25
Installing Live, starting on page DO 3-29
Changing an Objects Production Location, starting on page DO 3-38
Modifying and Testing ILE Objects, starting on page DO 3-44
Cancelling Checkouts and Deleting Objects, starting on page DO 3-45
Deleting Archived Objects, starting on page DO 3-46
Online Help Text
For detailed descriptions of the fields, options, and function keys displayed or
available at any of the panels shown in this document, please see the online
help text.
Moving Objects DO 3-1
Assumed Background
Understanding
This chapter assumes a basic understanding of Aldon LM(i). If you have

not yet read the Users Guide and Overview of Aldon Lifecycle
Manager (System i Edition), starting on page DO 1-1, please do so. Also,
you must define the application and release you are working with before
performing any of the functions described in this chapter. Chapters 7, 8,
10, 11, and 12 in the Setup and Administration Reference describe the
procedures for application and release definition.
Alternate Interfaces
Many functions described in this chapter may also be performed with

commands or user-defined PDM options provided by Aldon. See
Appendix F: PDM-Style User Options and Command Interface,
starting on page CG 7-1 of the General Topics Reference for details.
Checking Out Objects

Overview
Aldon LM(i) provides controlled access to source code through use of a
checkout function. The checkout function insures that only authorized
users check out source code and tracks object movement to insure that
changes within a release are performed cumulatively rather than in
parallel.
Copies of an object may exist simultaneously in Development,
Integration, Quality Assurance, and Production. You can only modify
source in the Development environment. When invoked, the checkout
function locates the most recently modified copy of an object and copies
it to the Development library associated with a designated developer. To
fix an urgent Production problem, use the emergency checkout to obtain
the Production copy of the object regardless of other copies that may be
active.
Aldon LM(i) automatically manages the library list for checkouts by
adding and then removing libraries for Integration, Quality Assurance,
and Production as necessary. Addition of these libraries to the system
portion of the library list by the user is contrary to the design of
Aldon LM(i) and may cause serious problems. See Chapter 1: Library
Lists in the General Topics Reference for more information.
Access the checkout function using the panel interface, the
ACMSCHKOUT command, the ACMSCHKFRN command, or
user-defined PDM options.
DO 3-2 Moving Objects
Eligible Objects
Objects in Integration, Quality Assurance, and Production are eligible for
selection by the checkout function. If the release has ancestors, ancestor
release Production environments are included in the library list for
checkouts. Objects requested for checkout that are not yet present in the
release are obtained from the Production environment of the closest
ancestor release. The ACMSCHKFRN command adds special checkout
access to objects in libraries outside of Aldon LM(i). Both source-based
and non-source objects are eligible for checkout.
Unless multiple checkout is allowed for the release, an object that is
already in Development for a given release cannot be checked out again
for that release until the Development copy is promoted back into the first
Aldon LM(i) testing environment. Objects are always eligible for
emergency checkout by users with the appropriate authority.
Eligible Recipients
All developers defined to Aldon LM(i) are eligible to receive objects
through checkout from any Aldon LM(i) release. The user performing the
checkout must have *ALL authority to the developer's source library. For
information on defining developers, see Defining Users, starting on
page SA 3-1. If a developer is likely to work on copies of the same object
from different releases at the same time, specify libraries different from
those specified by a developer's global developer definition for a given
application or release using application- or release-level developer
definitions as described in Chapter 9: Application Authorities and
Developers and Chapter 18: Working with Releases in the Setup and
Eligible Agents: Authority to Request or Perform

Checkouts
Grant authority to request or perform checkout operations for the entire
system or for each application. See the section Defaults for New
Releases in Chapter 2: Standard Global Setup Functions of the
Setup and Administration Reference for more information on request
requirements.
Object Flow
Checkout copies an object's source from testing or Production to
Development. There are two types of checkouts: standard and emergency.
The two types differ in the environment from which objects are checked
out and in the way objects checked out are later promoted. Figure 11 on
page DO 3-4 illustrates object flow for standard and emergency
checkouts.
For source-based objects, the checkout function copies source for the
selected object to the source library for the selected developer. The object
corresponding to the source is not copied since it is assumed that the
source is being checked out for modification and will be compiled to
create a new copy of the object. For non-source objects, the checkout
function copies the actual object to the object library for the selected
developer to serve as model for the new copy of the object. The exception
being objects specified with data option 2 (promote data) when both the
source and the object (including all data) are copied to the appropriate
development libraries.
A standard checkout obtains source from the environment closest to
Development. Aldon LM(i) searches the release's environments in
sequence from Integration through Quality Assurance, and Production.
This search sequence insures that the first copy encountered contains
all modifications that have been made to the object.
When you check an object out with the emergency checkout function,
Aldon LM(i) copies source from the Production environment, even if
there is a more recent active copy of the object.
Object Movement on Checkout

Emergency checkout always takes Production copy
Standard checkout takes copy closest to Development
Development
Integration *
Quality
Assurance *
Production
* These environments optional at release setup.
Figure 11 - Object Movement on Checkout
Ownership and Authority

For most checkouts, Aldon LM(i) creates a member in an existing source
file in the developer's library. If a source file of the correct type does not
exist, Aldon LM(i) creates one, assigns ownership to the user specified as
Owner of objects in the description of the receiving developer, and sets
*USE as the *PUBLIC authority.
Check out of Data Objects If the data object is set to Keep
Destination Data, just the source is copied to the development
environment library. In the case of a non-source based object, the
object is copied to the library without data. If the data object is set to
Promote Data, the object is copied to the library with all its data as
well as the source. For more information about the movement of data,
see Data, Data Libraries, and Data Sets starting on page CG 3-1 in
the Aldon LM(i) General Topics Reference.
Checkout of SQL Objects If the SQL object is defined with pseudo
source, just the source member is copied to the Development library.
If there is no source defined to Aldon LM(i), the checkout process
simply marks the object as checked out but does not copy/create the
object in the development environment library. This occurs because
there are many SQL objects that cannot be copied to a different
environment with the CRTDUPOBJ command.
Hint
For non-source SQL objects, you can still use option 5 to browse the
source that Aldon LM(i) generates for you or use option 43 (Generate
SQL pseudo source) to generate the source and change the object to use
pseudo-source. For more information see To create pseudo-source for an
existing SQL-based object starting on page UG 5-7 in the Aldon LM(i)
Users Guide.
Check Out With or Without Requests

The procedures for checking out objects vary depending on whether you
use checkout requests. If you use checkout requests, you can allow some
users to request checkout operations and others to actually perform them.
If you use requests, the movement process is separated into two steps. The
first step is the creation of a request. The second is the fulfillment of that
request. If you want to allow developers to request that objects be checked
out to them, but want a development manager or librarian to actually
review the requests and perform the checkout operations, you may want to
require requests. If you do not use checkout requests, a single operation
checks out objects. You can require some users to create requests to check
out objects and can allow others to perform checkout operations without
requests. You can perform emergency checkouts without requests even if
you require requests for standard checkouts.
Check Out With or Without Task Association

You can require a task identifier to complete a checkout. If a task
identifier is required, the object must either already be part of a defined
task at checkout, or it must be added to a new or existing task at checkout.
Users with Change task definition authority can add objects to an
existing task or define a new task when requesting or performing a
checkout. For users without this authority, the object must already be
included in the task they enter on the checkout panel.
Aldon LM(i) sets the value of the task for checkout according to the task
that is selected on Work with tasks or to the subset criteria for Work with
objects by release or developer.
For example, if you enter Work with tasks, select option 12 (Work with
objects) to work with the objects for the task, then request a checkout, the
task for the checkout operation defaults to the one you originally selected.
Selecting Additional Dependent Objects

Aldon LM(i) object referencing features may be used to identify all
objects dependent on those objects initially selected for checkout. This
allows assessment of the impact a change will have on other portions of
the application before the change is undertaken, and facilitates
implementing changes by speeding the checkout process.
Available Interfaces
Request checkouts through the Aldon LM(i) panel interface or with
Aldon-supplied PDM user options. Complete checkouts through the
Aldon LM(i) panel interface with the Checkout command,
ACMSCHKOUT; Checkout Foreign command, ACMSCHKFRN, or with
Aldon-supplied PDM user options. The following sections describe the
panel interface and System i commands. See PDM-Style User Options,
starting on page DO D-1 for a discussion of the PDM interface. Aldon's
user defined options also work with Hawkeye's Pathfinder
cross-referencing and documentation tool.
To create checkout requests

You can create checkout requests from:
Work with Objects by Release using option 13 (Request checkout*).
See Figure 7, Work with Objects by Release, View 1 of 3, on
page DO 2-6
Work with Objects by Developer using option 13. See Figure 19,
Work with Objects by Developer Panel, View 1 of 4, on
page DO 4-2
Work with Tasks panel using option 13. See Figure 2, Work with
Tasks panel, View 1 of 5, on page TT 3-4
1. Type 13 by one or more individual objects or tasks.
2. Press ENTER to display the Request Checkout panel shown in Figure
12, Request Checkout panel, on page DO 3-7.

This panel lists the objects selected and provides fields for entering
the developer to receive the objects, a task with which the objects are
associated, and a comment.
3. Press Page Up, Roll Down or F20 to view additional objects in the
list.
4. Complete these fields and press ENTER to create checkout requests for
the objects listed.

If you select several tasks for checkout requests on the Work with Tasks
panel, each task appears on a separate Request Checkout panel. When
selected by task, all the objects in a task must be assigned to the same
developer.
To deploy objects in a single task among several developers, select the
task with option 12=Work with objects instead of option 13 to display
objects in the selected task on the Work with Objects by Release panel.
On the Work with Objects by Release panel, select individual objects in
the task for checkout requests with option 13.
CRQSCHK
Request Checkout
Type the additional checkout information below, press Enter.

To developer . . . . . . . . . . . . .
PHILV
For task . . . . . . . . . . . . . . .
Comment for log . . . .
Change printer file
+ Name
+ Name
Objects selected for request checkout:

Object
Type
Release
DEMOCBL2
*PGM
ALDON/ACMSDEMO/BASE
1 objects selected for request checkout.

F3=Exit
F4=Prompt
F7=Add task
F16=Act upon dependent objects
F20=Enlarge list
F12=Cancel
F22=More functions
Figure 12 - Request Checkout panel
To developer
Type the developer name for the developer to whom you want the objects
checked out. Press F4 with the cursor in the To Developer field for a list of
existing values. All objects listed on the Request Checkout panel will be
requested for checkout to this developer.
For task
If you selected individual objects on the Work with Objects by Release or
Work with Objects by Developer panels, identify the task to which the
object belongs or to which it is to be added. Global- or application-level
options settings may require association of objects with a task for
completion of a checkout. The Task field is optional for checkout
requests, but the requirement, if present, is enforced when checkouts are
completed. Create a new task by pressing F7.
If you selected a task for checkout requests on the Work with Tasks panel,
the name of the task with which you are working is displayed and cannot
be changed.
Comment for log
Type a comment that describes the reason for the checkout operation. This
comment is written to the development log.
Press Enter to request checkout of the selected objects.
Checking out Objects

Fulfill checkout requests and checkout objects directly without checkout
requests with option 3 (Checkout) from one of several panels. Select one
or more individual objects on the:
Work with Objects by Release panel shown in Figure 7, Work with
Objects by Release, View 1 of 3, on page DO 2-6
Work with Objects by Developer panel shown in Figure 19, Work
with Objects by Developer Panel, View 1 of 4, on page DO 4-2
Select one or more objects with checkout requests pending on the Work
with Requests and Non-Conflict Conditions panel, shown in Figure 33,
Work with Requests and Non-Conflict Conditions panel, on
page DO 5-4.
Select one or more tasks on the Work with Tasks panel shown in Figure 2,
Work with Tasks panel, View 1 of 5, on page TT 3-4. Selecting a task
selects all objects associated with the task. For each task you can specify a
separate developer and checkout parameters.
Aldon LM(i) sets the value of the task for checkout according to the task
that is selected on Work with tasks or to the subset criteria for Work with
objects by release or developer.
After making your checkout selections, press ENTER to display the
Checkout Objects panel.
Transferring Objects Between Developers

To transfer an object from one developer to another, Aldon LM(i) moves
source, if available, and object, if available from the current developer's
source and object libraries to the new developer's source and object
libraries.
To transfer checked out objects between developers

1. At the Work with Objects by Developer panel, select the objects you
want to transfer with option 26 (Transfer*) and press ENTER.

The Transfer Objects panel displays:
CTFROBJ
Transfer Objects
Type the additional transfer information below, press Enter.

To developer . . . . . . . . . . . . .
Print transfer report . . . . . . . .
Run option . . . . . . . . . . . . . .
Comment for log
N
1
+ Name
Y=Yes, N=No
1=Run interactively,
2=Run in batch
. . . .
Checkouts selected for transfer:

Object
HIWORLDCL
Type
*PGM
Attribute
CLP
From
Developer
MARKE
Release
MARKE/MDE720/DELTA1
1 objects selected for transfer.

F3=Exit
F4=Prompt
F12=Cancel
F15=Full name
F20=Enlarge list
F22=More functions
2. At the Transfer Objects panel, in the To developer field, type the
name of the developer to receive the transferred objects.

3. Press ENTER to complete the transfer.
Emergency Checkouts
To request emergency checkout of the selected objects, use option 23
(Check out (emergency)*) on the:
Work with Objects by Release panel. See Figure 7, Work with
Objects by Release, View 1 of 3, on page DO 2-6
Work with Tasks panels. See Figure 3, Work with Tasks panel, View
2 of 5, on page TT 3-5.
After selecting objects, press ENTER to display the Emergency Checkout
panel. The emergency checkout function always obtains source from the
Production copy of the object regardless of any active copies that may
exist. Objects checked out with the emergency checkout function return
directly to Production when promoted from Development bypassing all
testing environments.
Checking Out Files for a Child Release

If you are developing using multiple releases and are checking out files,
some care must be taken to ensure that relationships of logical files to
physical files are maintained.
Recommendation
If you check out a physical file to a child release, and that physical file has
logical files over it, Aldon strongly recommends that you also checkout
any logical files built over that physical file.
If you do not check out the logical files, you may receive level checks or
other undesirable results later. Aldon LM(i) may also fail to recreate the
modified physical file in data sets associated with the child release.
Promoting Objects
In Aldon LM(i), any movement forward from development or testing
toward Production is a promotion. In every standard promote, the
promoted source and objects move forward to the next environment. An
object checked out with the emergency checkout function moves from
Development directly into the Production environment on promotion,
bypassing any intervening test environments.
Aldon LM(i) automatically manages the library list for promotes by
adding and then removing libraries for Integration, Quality Assurance,
and Production as necessary. Addition of these libraries to the system
portion of the library list by the user is contrary to the design of
Aldon LM(i) and may cause serious problems. See Chapter 1: Library
Lists in the General Topics Reference for more information.
Access the promote function using the panel interface, the command
interface, or the user-defined PDM options provided by Aldon.
Eligible objects
Conflict free objects in active environments are eligible for promotion. An
object with a conflict condition pending cannot be promoted until the
condition is cleared. These events cause Aldon LM(i) to create a conflict
condition:
1. Checkout of an object when a copy already exists in the development
environment (this can only happen if multiple checkouts are allowed).

2. Emergency checkout of an object already active or in development
(promotion or the pre-existing active copy is blocked).
3. Unsuccessful attempt by Aldon LM(i) to update a data set for which
Monitor for update errors is set to Y (Yes) during promotion of a

file.
4. If you are working with multiple releases of an application, changing
the production copy of an object or checking an object out for

modification in one release creates a conflict condition on each copy
of the object in each notified release.
To clear a multiple checkout or emergency checkout conflict condition,
examine the versions of the object in conflict as indicated by the Work
with Conflicts panel (Figure 34, Work with Conflicts Panel, on
page DO 5-8) and merge the changes. Clear the conflict and promote the
object containing the merged changes.
To clear a data update failure, request an update of the data libraries.
Since the update failure may have affected testing of the file, check to
insure that the file has been tested correctly. Remove the condition using
the Work with Requests and Non- Conflict Conditions panel (Figure 33,
Work with Requests and Non-Conflict Conditions panel, on
page DO 5-4). For more information, see Data, Data Libraries, and
Data Sets starting on page CG 3-1 in the Aldon LM(i) General Topics
Reference.
Promotion of objects with release conflicts as far as some designated
environment may be permitted depending on the Allow promotions with
conflicts to release option for the release. For more information see
Allow promotes with conflicts to starting on page SA 2-11 in the
Aldon LM(i) Setup and Administration Referenceand consult your
Aldon LM(i) administrator.
Eligible Agents: Authority to Request or Perform

Promotes
Grant users authority to request or perform promotes by environment, for
the entire system or for specific applications or releases. Objects checked
out with the emergency checkout function can be promoted without
requests even if you require requests for standard promotions. For more
information see:
Working with Users and User Classes starting on page SA 3-2 in
the Aldon LM(i) Setup and Administration Reference
Specifying Application Authorities, starting on page SA 11-1
Overview of Release Functions starting on page SA 13-1 in the
Aldon LM(i) Setup and Administration Reference
Object Flow
A standard promotion moves an object from its current environment
towards Production one environment at a time. Promotion of an object
checked out with the emergency checkout function moves the object
directly from Development into the Production environment.
Figure 13 illustrates object flow for standard and emergency promotions.
Standard Promotions
Development
* optional environments
Integration*
Quality
Assurance*
Production
Emergency Promotion
Figure 13 - Object Movement on Promotion
During a promote, Aldon LM(i) moves source and object from the from
environment to the to environment. If the promote is successful, Aldon
LM(i) removes the promoted source and object from the from
environment when the promotion completes successfully. If a promotion
is unsuccessful, source and object remain in the from environment. If
there is a copy of the object and source in the to environment that would
have been replaced by a successful promotion, it remains intact.
Session Protection
To protect active jobs that might be using programs deleted or replaced by
promotion, Aldon LM(i) copies old versions of programs to the IBM
managed library QRPLOBJ before deleting them after a successful
promotion. (Aldon LM(i) also copies old versions of programs to
QRPLOBJ when creating in place, deleting an active copy on checkout,
installing a deployment on a remote system, replacing objects with the
Load function, and when deleting objects from a release.) For details on
use of QRPLOBJ by Aldon LM(i) see Aldon Lifecycle Manager for
System i Technical Details, starting on page CG 6-1.
Creating vs. Moving

Use release-level options to specify whether to recompile source on
promotion into each active Aldon LM(i) environment or move the
existing objects and associated source without recreating objects.
Set defaults for the release-level options at the global and application
level. See the section Production Environment Options in Chapter 2:
Standard Global Setup Functions and the section Specify Default
Options for New Releases in Chapter 8: Defining a New Application.
Source members that are not associated with a specific object (for
example, copy members) and non-source objects are promoted without
compilation regardless of your option settings.
Creating on Promotion
When you create objects on promotion, Aldon LM(i) constructs a library
list to use for the creation job. The constructed list uses and prioritizes
libraries from the different Aldon LM(i) environments to reference
appropriate copies of each source member and object during compilation.
The library list for creating objects on promotion to Integration includes
Integration, Quality Assurance, and Production libraries. (If you are not
using some of the optional environments, the corresponding libraries do
not exist and are not included in the list.)
Under the same conditions, the library list for creating objects promoted
to Quality Assurance includes Quality Assurance and Production
libraries. The library list used to create objects on promotion to
Production includes only Production libraries. You can add libraries that
are not a part of your release to the end of the compilation library lists by
changing the job description used by the promotion jobs. See Creating
Objects with Shared Applications starting on page CG 1-11 in the
Aldon LM(i) General Topics Reference for information on sharing
programs and files among multiple applications automatically through
definition of a shared application.
Note
Use of qualified names to find copies of referenced objects in specific

libraries instead of relying on the library list is contrary to the design of
Aldon LM(i) and is not recommended.
To re-create objects on promotion, Aldon LM(i) uses either the IBM
supplied create command for the object type and attribute or a user
defined create command. Unique user or software vendor supplied create
commands can be defined to Aldon LM(i) at the global or application
level. See Chapter 19: Custom Object Creation Setup and the section
Defining Custom Create Commands in Chapter 10: Working with
Applications for more information on defining create commands.
With either type of command you can use creation parameter defaults set
at the global, application, or release-level. For IBM supplied create
commands, you can direct Aldon LM(i) to use the command parameter
values that were used to create the copy of the object you are promoting,
or you can set the command parameter values for that specific copy of the
object prior to the promotion. Set command parameter values for a
specific copy of an object as described in Single-Copy Create
Specifications on page DO 4-16. For custom create commands Aldon
LM(i) must use your defaults.
Re-creating objects on promotion ensures that matching source and
objects are kept together, and increases the probability that copies used
for testing are also used for re-creation.
Moving on Promotion
If you direct Aldon LM(i) not to create new copies of objects on
promotion, existing objects move forward with the source. This uses less
system resources than for compilations. However, if an object that
depends on changed objects in the from environment is moved forward
without those referenced objects and is not recreated in the to
environment, you may experience level checks and unpredictable results
when testing in the to environment. This is due to the fact that the
referenced objects in the testing library list may be different from the ones
used for compilation.
Level Checks
If you create objects as you promote them forward, and you promote one
object, then you promote an object that it references or depends on, you
may still experience level checks. For example, you promote a program
and then a display file that is used by that program. The program was
compiled with the older copy of the display file. Eliminate level checks in
this type of situation by compiling the program in place with option 14
(Create*) on the Work with Objects by Release panel.
Dependent Objects
Aldon LM(i) object referencing features may be used to avoid level
checks. If object dependency data is kept current, you can locate, select,
and recreate dependent objects automatically or manually during
promotion or select a promoted object with option 41 or 42 to locate and
recreate dependent objects after promote completes.
Aldon LM(i) can locate and recreate dependent objects in the same
release, in other descendent releases, and, if the promoted object is in a
shared application, in sharing releases of other applications.
You can also elect to leave a copy of objects resident in the Promote from
environment when you promote them. You may want to leave copies
resident on promote if you need a full set of objects to perform testing in a
development or testing environment. You can selectively leave objects
resident if objects dependent on them are remaining in the environment.
For more information see the online help for the Leave resident field on
the Promote Objects panel (To promote an object starting on page
UG 2-25 in the Aldon LM(i) Users Guide).
Leave resident option
Note
The leave resident function is not supported for the Development

environment.
Ownership and Authorities

When you promote an object, Aldon LM(i) assigns an owner to the copy
of that object in the to environment and sets authorities to control access
to it. This prevents unauthorized changes to source members and objects
in the Integration, Quality Assurance, and Production environments.
Aldon LM(i) can use the defaults that work well for many sites to set
ownership and authorities or Aldon LM(i) can set them based on specially
created or existing copies of the objects you have specified as reference
objects. For details on the use of Aldon LM(i) defaults, reference objects,
and reference libraries to set ownership and authorities, see Ownership,
Authorities, and Reference Libraries, starting on page CG 2-1, and also
Chapters 2, 8, and 12 in the Setup and Administration Reference.
Physical Files and Tables

Associated Files
As you promote a physical file or table, Aldon LM(i) performs additional

steps to ensure that any associated logical files that reference it can be
used for testing with the new physical file. When Aldon LM(i) promotes a
physical file, it checks for links to logical files outside of Aldon LM(i). If
a link between a physical file inside Aldon LM(i) and a logical file outside
of Aldon LM(i) is found, Aldon LM(i) blocks the promotion and issues an
error message. To complete the promotion, exit Aldon LM(i) and
eliminate the link by deleting the logical. Return to Aldon LM(i) and
complete the promotion. Recreate the logical outside of Aldon LM(i)
after promotion has completed, if you wish.
Data Option
Data is copied on promotion depending on the data option set for the file.
For more information about data options, see Promote with Data on
page IN 3-16 in the Aldon LM(i) Installation and Upgrade Guide and
Data Option on page DO 4-14 in the Aldon LM(i) Daily Operations
Reference.
Logical Files
When you promote a logical file, Aldon LM(i) performs additional steps
to ensure that it does not point to a physical file in another environment.
When necessary, logical files are recompiled upon promotion rather than
moved regardless of the value entered for the move/compile option. See
Aldon Lifecycle Manager for System i Technical Details, starting on
page CG 6-1 for important information about physical and logical file
handling in Aldon LM(i).
Handling Data on Promotion

When promoting a data object with the default setting of Keep
Destination Data, Aldon LM(i) either updates the existing data with the
new format or if the file does not exist, creates an empty copy of the file.
The exception being on promotion to ITG or QUA where no data is
preserved in the environment libraries, but the data in any attached data
set is preserved. Optionally, a user supplied conversion program can be
executed to update the existing data to the new format.
If the data object is set to Promote Data, both the environment library and
any specified data set libraries are updated with the new data object
format and all existing data is replaced with the data from the from
environment library. See Data, Data Libraries, and Data Sets, starting
on page CG 3-1 for more information.
Deploying on Promote
Once objects have been changed, they can be promoted using either the
deploy on promote or install live on promote function.
You can deploy objects during promotion to Integration, Quality
Assurance, or Production to place objects on a remote processor for
integration or quality assurance testing or for production use. For more
information about object deployment, see Object Deployment starting
on page UG 3-6 in the Aldon LM(i) Users Guide.
Install live is used in conjunction with the promote function. For example,
when you promote objects forward from Integration to QA, you can
simultaneously initiate install live of the same objects into the QA install
live target. For more information about installing live, see Installing
Live, starting on page DO 3-29.
Third Party Cross Referencing Files Update on

Promotion to Production
If your site has Abstract/Probe+ from ASC or Hawkeye's Pathfinder
installed, Aldon LM(i) can automatically update cross-referencing files
each time a job promotes objects into Production. For more information,
see ABSTRACT/PROBE+ starting on page TI 1-1 in the Aldon LM(i)
Additional Interfaces Reference.
Promotion With or Without Requests

You can set release options to require promotion requests prior to actual
promotion into some or all of the environments for a release. For example,
you could allow promotion into Integration without a prior request, but
could require a request for promotion into the Quality Assurance
environment. If you require promotion requests, you can allow some users
to request promotes and others to actually perform them. You can require
some users to create requests to checkout or promote an object and can
allow others to perform promotes without requests.
If you use requests, the promotion process is separated into two steps. The
first is the creation of a promotion request. The second is the fulfillment
of that request. If you do not require promotion requests, a single step
promotes objects. Refer to the section Production Environment Options
in Chapter 2: Standard Global Setup Functions, the section Specify
Default Options for New Releases in Chapter 8: Defining a New
Application, and the section Specify Release Options in Chapter 12:
Defining a Release in the Setup and Administration Reference to set
options for promoting with or without requests.
Request promotes through the Aldon LM(i) panel interface with the
Request Promote Objects command, ACMSRQSPRM, or with
Aldon-supplied PDM user options. Perform promotes through the
Aldon LM(i) panel interface with the Promote command,
ACMSPROMOT, or with Aldon-supplied PDM user options. The
following sections describe the panel interface. See Appendix F:
PDM-Style User Options for a discussion of the PDM interface. See
Command Interface, starting on page CG 7-1 for a discussion of the
Command interface.
Creating Promotion Requests

Promotion requests may be optional or required depending on the release
options and a user's authorities. Create promotion requests with option 17
(Request promote) from the Work with Objects by Release panel
(Figure 7 on page DO 2-6), the Work with Tasks panel (Figure 3 on
page TT 3-5), or the Work with Objects by Developer panel (Figure 19 on
page DO 4-2). Type option 17 by one or more individual objects or tasks
and press ENTER to display the Request Promote panel.
Promoting Objects
Access to Object Promotion
Promote objects by using option 7 to select:
Objects on the Work with Objects by Release panel shown in Figure 7
on page DO 2-6.
Objects on the Work with Objects by Developer panel shown in
Figure 19 on page DO 4-2.
Objects with promote requests pending on the Work with Requests and
Non-Conflict Conditions panel shown in Figure 33, Work with
Requests and Non-Conflict Conditions panel, on page DO 5-4.
Tasks with associated objects on the Work with Tasks panel shown in
Figure 3 on page TT 3-5.
Emergency Checkout and Promotion

Perform emergency checkouts by selecting the desired objects with option
23 (Emergency checkout) and completing the Emergency Checkout
panel, which is very similar to the standard checkout panel (Figure 12 on
page UG 2-13). Aldon LM(i) maintains a record of objects checked out
with the emergency checkout function and moves these objects directly
back into the Production environment on promotion. Promotion requests
are never required when promoting objects checked out with the
emergency checkout function regardless of the requirement for standard
objects.
Data set update and deployment occur during the promote the same way
as a normal promote to production. An acknowledgement condition is
always set on when an emergency checkout is promoted; this enables easy
tracking of all moves to production that did not go through the normal
testing path.
Moving Objects to a Parent Release

Aldon LM(i) now supports two methods to move objects to the parent
release:
Promote to parent Follows the standard promote options
recompiling the object if required. Data options for the individual
objects are observed. Version numbers are updated. Data sets are
updated and deployment sets automatically created.
Merge to parent Provides the ability to move the objects to the
parent release without any changes. For example, the object is always
copied, the version number does not change, and the data option can
be overridden. Data sets are updated but no deployment is done
following either a promote or merge to parent.
Terminology: Child vs. Delta
Every Delta release is a child release of some parent. However, some

Delta releases may also be parents. To avoid confusion, this discussion
uses child or child Delta rather than Delta to refer to the release you
are promoting from when you promote into the parent release.
Capabilities and Features of the Promote to Parent

Function
The promote to parent function has the following capabilities:
Select objects individually or by task. See To promote individual
objects to parent, starting on page DO 3-21 and To promote to
parent by task, starting on page DO 3-24.
A request promote to parent function is available. See To request
promote to parent, starting on page DO 3-25.
Deploy on promotion to parent. You can automatically create a
deployment set while promoting to a parent release. See Step 5 in
To promote individual objects to parent on page DO 3-21.
Data conversion on promote to parent
Data conversion options supported for normal promotes are also
supported for promote to parent. See Specifying Data Conversion
Options, starting on page CG 3-32.
Effects of Promote to Parent

Promoting objects to a parent release has the following effects:
The effect on the data in the parent release depends on the data option
set for the object.
Warning: When you promote a physical file to the parent release,

Aldon LM(i) deletes the Production copy of the physical file in the
from release including any data it contains.
The library group and physical library of the promoted object and
source are set to match the library groups of the object and source it is
replacing in the parent. If the object is new to the parent, LM(i) assigns
the library groups using the same method as if the object was being
added as new. The library group of the object in the parent can be
changed either before or after the promote by using option 9
(Move/define).
When you promote a source based object to a parent release,
Aldon LM(i) puts the source in the file and member defined for the
object in the parent release.
Warning: If the record length in the parent source file is shorter than
that of the child release source file, Aldon LM(i) truncates the source
records as necessary. A message to this effect appears on the promote
report.
If the object is not defined in the parent release, Aldon LM(i) puts the
source in the location specified in the child release and creates the file
if necessary.
Note
You can change the location of an objects' source in a release using 9

(Move/Define) on the Work with Objects by Release or Work with
Objects by Developer panels.
Aldon LM(i) deletes and recreates logical files as needed.
As with a standard promote, the promoted object is no longer in the
promote from environment
If a copy of the promoted object is active (in Development,
Integration, or Quality Assurance) in the parent release, Aldon LM(i)
creates a C P release conflict on the active copy
Aldon LM(i) creates a C R release conflict on each copy of the
promoted object in notified releases of the parent release (other than
the promote from release)
If the promoted object is associated with a task in the child release:
Prerequisites
The association is preserved
Aldon LM(i) associates the parent release with the task if the
association was not already defined
Upon automatic creation of an association of the parent release

with the task, Aldon LM(i) sets the allow object activity flag to
N=No for the parent release in the task definition
The following prerequisites are common to promoting both individual

objects and tasks to a parent release:
The release option Allow promote to parent must be set to Y in the
child Delta release
You must have Perform promotion from child authority in the parent
release
Objects must be in the Production environment of the child Delta
release
Objects cannot be a member of any unextracted deployment sets
created on promotion into the child release Production environment
Objects need not exist in the parent release
To promote individual objects to parent

1. At the Aldon LM(i) main menu, type 1 (Work with objects by
release) and press ENTER to display the Work with Objects by Release
panel.
2. At the Work with Objects by Release panel, in the Opt field by the
objects you want to promote, type 27 (Promote to parent) and press

to display the Promote Objects to Parent panel:
ENTER
CPRMOBJPRN
Promote Objects to Parent
Release . . . . . . . . . . . :
To parent release . . . . . . :
ALDON/ACMSDEMO/DELTA1
ALDON/ACMSDEMO/BASE
Type selection, press Enter.

Press Enter with no selection to continue.
Create dependent objects
. .
Dependent objects selected:

Leave resident . . . . . . .
1=Select all objects,

2=Display list for individual selections,
5=Display selections
2
1=All, 2=None, 3=Dependent
Objects selected for promote to parent:

From
Object
Type
Attribute
Library
NEWAREA
*DTAARA
PF
ACMDL1PDN2
F3=Exit
F12=Cancel
To
Library
To be set
1 objects selected for promote.

F22=More functions
Figure 14 - Promote Objects to Parent panel

3. Optionally, in the Create dependent objects field, type an option
number and press ENTER to work with creation of dependent objects.

4. Leave the Create dependent objects field blank and press ENTER to
proceed with the promotion.

5. If you are promoting a data object, the Specify Data Conversion panel
displays next. See To specify data conversion on promote, starting

on page CG 3-32 for more information.
6. After completing any required data conversion specifications, if
Aldon LM(i) cannot determine the correct library group for an object
in the parent release, the Specify Libraries for Promotes and Creates
panel displays:
CCRTMAP
Specify Libraries for Promotes and Creates
Libraries cannot be mapped to the parent or non-resident release in which the

following objects are to be created.
Press Enter with no options to continue.
2=Specify libraries
Opt
2
Object
NEWAREA
Type
*DTAARA
F3=Exit
F10=View 3
F16=Review objects
Attribute
Create in
Release
ACM/BAS
From
Release
ACM/DL1
F11=View 2
F12=Cancel
F22=More functions
This panel lists one record for each object for which you must assign
library groups.
Do the following:
a.
Press ENTER to display the Select Library Group for Object

panel for the first object in the list:
CSELOBJLGP
Select Library Group for Object
Object . . . . . . . :
Object type . . . . :
NEWAREA
*DTAARA
Application . . . . :
To release . . . . . :
ALDON/ACMSDEMO
BASE
Object attribute . . :
Extended attribute . :
Data object . . . . :
No
From release . . . . :
DELTA1
Library group for the object cannot be mapped between releases.

Type option, press Enter.
1=Select (one only)
Opt
F3=Exit
F4=Prompt
b.
Production
Library
ACMBASPDN1
ACMBASPDN2
ACMBASPDN3
ACMBASPDN4
Library Group
01 Programs
02 Files
03 Source
04 Other
F9=Retrieve
F12=Cancel
F22=More Functions
Type 1 (Select) in the Opt field to assign the object library

group. Press ENTER to continue.
If the object is source based, the Select Library Group for Source
panel displays:
CSELSRCLGP
Select Library Group for Source
Object . . . . . . . :
NEWAREA
*DTAARA
To release . . . . . :
Object library group :
ALDON/ACMSDEMO
BASE
04 Other
Object attribute . . :
Data object . . . . :
No
DELTA1
Library group for the source cannot be mapped between releases.

1=Select (one only)
Opt
Production
Library
MDEBASPDN1
MDEBASPDN2
MDEBASPDN3
MDEBASPDN4
Library group
01 Programs
02 Files
03 Source
04 Other
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F22=More Functions
c.
Type 1 (Select) in the Opt field to assign the source library

group. Press ENTER to continue.
d.
Continue to perform Steps b. and c. until all library group

assignments have been made.
When you finish assignments for the last object, the Specify
Libraries for Promotes and Creates panel displays again.
Do one of the following:
To change library group assignments for an object, in the Opt field

by the object, type 2 (Specify libraries) and press ENTER
To continue with the promote job, press ENTER with no options

selected
After you complete library group assignments and press ENTER, the
Specify Promote Options panel displays:
CPRMOPT
Specify Promote Options

Stop upon failure . . . . . . . .
Print compile listing . . . . . .
N
N
Y=Yes, N=No
Y=Yes, N=No
Leave resident . . . . . . . . . .
1=All, 2=None, 3=Dependent
Install live from PDN
. . . . . .
Y=Yes, N=No
Deploy from PDN
. . . . . . . . .
Y=Yes, N=No
Comment for log
. . . .
F3=Exit
F5=Refresh
F19=Submit without prompt
F12=Cancel
F16=Review objects
F22=More functions
Figure 15 - Specify Promote Options panel

Note
You can use the Install live from PDN field or the Deploy from
PDN field to create a deployment set for the objects you are
promoting.
7. On the Specify Promote Options panel, complete options as desired
and press ENTER to display the Submit Job panel.

8. At the Submit Job panel, complete options as desired and press ENTER
to submit the promote job.
To promote to parent by task

When using Promote to parent on a task, only eligible objects (those in
Production) are promoted. Other objects associated with the task are not
promoted.
1. At the Aldon LM(i) main menu, type 5 (Work with tasks) and press
ENTER
to display the Work with Tasks panel.
2. At the Work with tasks panel, in the Opt field by the task you want to
promote, type 27 (Promote to parent) and press ENTER to display the

Promote Objects to Parent panel.
To request promote to parent

Use of promote to parent requests is optional. Sites use requests if they
want to more finely divide and control responsibilities and authorities for
this function. Contact your Aldon LM(i) administrator for more
information.
The release option Allow promote to parent must be set to Y in the
child Delta release
Prerequisite
1. At the Aldon LM(i) main menu, type 1 and press ENTER to display the
Work with Objects by Release panel.

objects you want to promote, type 37 (Request promote to parent)

and press ENTER to display the Request Promote to Parent panel.
You can also request promote to parent of a task from the Work with
Tasks panel or use the command ACMSRQSPMP.
Note
3. Complete the fields on the Request Promote to Parent panel and press
ENTER
to submit the request.
Merging Objects into a Parent Release

Merge Objects into Parent Release was introduced to replace some of the
functionality lost when the option to merge releases was removed.
Accessed from the Work with Objects by Release Panel, Merge Objects
into Parent (option 50) allows you to move the current production version
of an object from a child (delta) release to its parent release without doing
all of the processing associated with a promote to parent.
The Merge Objects into Parent Release option is only available for objects
in the production environment of a delta release, when there are no active
copies of the object in either the child or parent release. That is you can
only execute the merge if there are no copies in DVP, ITG, and QUA in
either release.
Note
Although we use the term MERGE, for compatibility with the old action,
no merging of source members or data is performed during the process.
The child source and object replaces the existing parent source and object.
There are some options with regards to data that are explained further on
in this section.
Selecting Objects to Merge

You can merge objects individually or in groups, merge all of the objects
in the production environment of a delta release simultaneously, or you
can use the Subset Objects by Release List panel (F17) to select a subset
of the objects to merge.
Merging Selected Objects by
Batch Job
A single batch job is submitted to merge all of the selected objects.

During the batch portion of the merge, objects and source are copied into
the parent release production libraries, replacing existing parent source
and objects. Replaced source and objects are archived prior to being
replaced, if archiving is active for the application.
The CRTDUPOBJ command is used to process most objects to ensure
that an exact copy of the child release object is placed in the parent
release. In cases where CRTDUPOBJ is not possible, the object is
re-created in the parent release libraries. Examples of object types where
CRTDUPOBJ is not used include logical files, SQL indexes and views,
and stored procedures.
Task/Release Connections Made Automatically

If the child release object has task associations, those associations are
carried forward to the parent release.
If the child release object has special creation options defined, they are
also moved forward to the parent release.
Merging Produces Multiple Log Entries

The merge objects into parent function generates log records for both the
From child release and the To parent release. The two log records
ensure visibility to users tied to either release.
Merging Does Not Change Object Version

Numbers
Version numbers are not altered as part of the merge process. The existing
merge-from (child) object version number is retained in the new object.
Merge Objects into Parent vs. Promote to Parent

Regardless of settings, merged objects are not compiled into the
release
Version numbers do not change. The existing version number is
retained in the new object
You can override the data option settings for Keep destination data and
Promote with data
Log entries are indicated with MGC (Object merged to parent (child
record)) and MGP (Object merged to parent (parent record)) versus
promote entries of PRC and PRP
Data sets are updated
Deployment sets are not created including install live
No exit programs are executed
Object cannot be active in either release
No conditions
To merge individual objects into parent

1. At the Aldon LM(i) main menu, type 1 (Work with objects by
panel.
objects you want to promote, type 50 (Merge into parent) and press
ENTER.
The Merge Objects into Parent panel displays.

CMRGOBJPRN
Merge Objects into Parent
Release . . . . . . . . :
Into parent release . . :
BONNIEM/TEST731/DELTA
BONNIEM/TEST731/BASE

Use child data . . . . .
Stop upon failure . . .
N
Y
Y=Yes, N=No
Y=Yes, N=No
Objects selected for merge into parent:

From
Object
Type
Attribute
Library
ACTGLP
*FILE
PF
B74DELPDNF
WARNING: Data in merged objects may be lost.

F3=Exit
F12=Cancel
F15=Full name
To
Library
B74BASPDNF
See "Use child data."

F22=More functions
Figure 16 - Merge Objects into Parent panel

3. The Use child data field displays only if at least one of the objects
selected is defined with Data option set to Keep destination data.

Type Y (Yes) if you want the data from the child copy of the data
object to replace the data in the parent copy of the object.
Type N (default) if you require the data in the parent copy of the
object to be preserved. If left to N the next screen will allow the entry
of Data Conversion options.
If the Use Child Data field is left as N, pressing enter displays the
Specify Data Conversion panel. Use this panel to define CPYF
options and/or specify a custom data conversion program. For more
information, see Defining Data Conversion Options starting on
page DS 8-25 in the Aldon LM(i) Object Deployment Reference
and To specify data conversion on promote starting on page
CG 3-32 in the Aldon LM(i) General Topics Reference.
Note
If there are data objects to be promoted to the parent with differing

Use child data needs (some Y, some N), then they must be merged in
separate jobs.
This option is available to provide compatibility with the old merge
release function. If you enter Y, only the copy of the object in the
parent environment library is updated with the new data. The format
but not the data in any data set or deployment target is updated. If that
data in all libraries is to be replaced, the data object in the child
should be changed to data option Promote Data before the merge.
4. In the Stop upon failure field, if you are merging several objects and
do not wish for the job to continue if the merge of a single object fails,
type Y.
5. The objects selected for merge are listed. If an object is not valid for
Merge to Parent, the reason code displays under the To Library

column. The following reason codes can display:
*ACTIVE the object is still active in either the parent or the child
release. Active means there is a copy in either DVP, ITG, or
QUA.
*CONFLICT There is a conflict on the Child Release copy of the
object that must be cleared before the merge can take place.
*CONDITION There is a condition on the child release copy of
the object that must be cleared before the merge can take place.
*NOT ABLE the object is not eligible for merge to parent. Applies
to non-source based LFs and *CONTAINs.
Note
If both *CONFLICT and *CONDITION, *CONFLICT displays.

6. Once you have completed specifying your options, press ENTER to
display the Submit Job with Varying Library Lists panel.

7. At the Submit Job with Varying Library Lists panel, change default
values for the merge job, if necessary. Press ENTER to submit the
merge job.
Once each object has been successfully merged, the child copy is deleted.
If an error occurs during the merge process, the child release copy is left
intact and the job stops or continues according to the option selected. The
replaced parent copy is archived according to the archive rules for the
application, the same way as a promote to parent works.
Installing Live
For an introduction to install live see Install Live Concepts on page
UG 2-31 in the Aldon LM(i) Users Guide
For an introduction to install live and additional end user topics see
Installing Live starting on page UG 2-29 in the Aldon LM(i) Users
Guide.
For information on configuring install live and recovering from error
conditions, see Installing Live starting on page DS 7-1 in the Aldon
LM(i) Object Deployment Reference.
Additional Install Live Features

Install live by task
You can use the install live function from the Work with Tasks panel to
select all objects in a task for install live. This works even on tasks with
objects in multiple releases. In such cases Aldon LM(i) helps you create
several install live jobs in the same submit process, one for each
environment containing task objects you want to install live.
Install live requests
You can grant authority to request install live and authority to initiate
install live jobs to different users just as you can for the checkout and
promote functions.
Multiple targets per environment
You can define multiple targets to receive install live deployments for a
given environment. In such cases all defined targets receive all install live
deployments for that environment. The user cannot pick and choose
targets when defining the install live job. For greater flexibility you can
use the standard deployment function.
Library group selection in

deployment profile controls
content sent to targets
You control the content deployed to targets during install live

configuration by selecting library groups in the deployment profile for the
release environment. For example, you could select library groups
containing programs and data objects, but not select library groups
containing source code.
Possible to block installation of a

library group for an individual
target definition
For most purposes, in target definitions you define a library to receive

content for each library group in the release, and let the deployment
profile limit what content is sent. In some circumstances it may be useful
to exclude some content from automatic installation at a target. You can
do this by not mapping the library group to an installation library in the
target definition. For example, you could create a target definition that
prevents installation of the library group containing object source.
Changing Install Live Default Values

To change the install live comment
Perform the steps in To install live on promote starting on page
UG 2-32 in the Aldon LM(i) Users Guide. When you reach step Step 5
on page UG 2-33, be sure to type 1 (Change comment for log). When you
press ENTER, the Install Live Definition panel displays:
Prerequisite
CINSLIVDFN
Install Live Definition
Release . . . . . . . . :
Environment . . . . . . :
DOUGS/DMS01/DELTA
PDN

Comment for log
Command ===>
F3=Exit
. . . .
F5=Refresh
F12=Cancel
F22=More functions
At the Install Live Definition panel, in the Comment for log field,
modify the comment as desired and press ENTER.
Go to Step 6 on page UG 2-34.
To change the install live schedule

Prerequisite
Do either of the following:

UG 2-32 in the Aldon LM(i) Users Guide. At step Step 5 on
page UG 2-33, be sure to type 2 (Change schedule).
Perform the steps in To install live outside of the promote function
starting on page UG 2-35 in the Aldon LM(i) Users Guide. At Step
5 on page UG 2-36, in the Schedule field, be sure to type Y (Yes).
When you press ENTER, the Install Live Schedule panel displays:
CINSLIVSCD
Install Live Schedule
Release . . . . . . . . :
DOUGS/DMS01/DELTA
PDN
Start send . . . . . . .
Start receive . . . . .
Start install . . . . .
----- Schedule ---Date

Time
*CURRENT
*CURRENT
*CURRENT
*NODELAY
*CURRENT
*NODELAY
Schedule date (*CURRENT,

*MONTHSTR, *MONTHEND,
*MON, *TUE, *WED, *THU,
*FRI, *SAT, *SUN, date)
Schedule time (*CURRENT,
*NODELAY, time)
Command ===>
F3=Exit
F5=Refresh
F12=Cancel
F22=More functions
At the Install Live Schedule panel, modify the Date and Time values
for the send, receive, and install steps as desired and press ENTER.
If you are installing live on promote, go to Step 6 on page UG 2-34.
If you are installing live outside of promote, do one of the following:
If the next job attribute you chose to modify was installation

method defaults, the Specify Install Live Method panel displays.
Go to To change the install live installation method, starting on
page DO 3-31.
If the next job attribute you chose to modify was data conversion
specifications, the Specify Data Conversion panel displays. Go to
To change install live data conversion specifications, starting on
page DO 3-33.
If you did not select any additional job attributes for modification,
the Submit Job panel displays. Go to To complete the install live
outside of promote starting on page UG 2-37 in the Aldon LM(i)
Users Guide.
For more information on the send, receive, and install steps, see
Deploying the Set starting on page DS 1-8 in the Aldon LM(i) Object
Deployment Reference.
To change the install live installation method

Prerequisite

UG 2-32 in the Aldon LM(i) Users Guide. At Step 5 on
page UG 2-33, be sure to type 3 (Change installation method).
5 on page UG 2-36, in the Installation method field, be sure to type Y
(Yes).
When you press ENTER, the Install Live Method panel displays:
CINSLIVMTH
Specify Install Live Method
Release . . . . . . . . :
DOUGS/DMS01/DELTA
PDN

More:
Installation method
. .
If method 3 or 4:
DB file or program . .
Library . . . . . .
Member (of DB file)
Command ===>
F3=Exit
Name
Name
Name, *FIRST
F5=Refresh
CINSLIVMTH
1=Auto install,3=DB job,

4=Program
F12=Cancel
F22=More functions
Specify Install Live Method
Release . . . . . . . . :
DOUGS/DMS01/DELTA
PDN

More: If method 2:
Function at begin . .
Command or program
Library . . . . .
Parameters . . . . .
Function at end . . .
Command or program
Library . . . . .
Parameters . . . . .
Command ===>
F3=Exit
F5=Refresh
1=Command, 2=Program, 9=None

Name
*RCVLIB, *LIBL, name
1=Command, 2=Program, 9=None

Name
*RCVLIB, *LIBL, name
F12=Cancel
F22=More functions
At the first and second pages of the Install Live Method panel, modify
values controlling installation of the objects at the targets as desired
and press ENTER.
If you are installing live on promote, go to Step 6 on page UG 2-34.
If you are installing live outside of promote, do one of the following:
If the next job attribute you chose to modify was data conversion
specifications, the Specify Data Conversion panel displays. Go to
To change install live data conversion specifications, starting on
page DO 3-33.
If you did not select any additional job attributes for modification,
the Submit Job panel displays. Go to To complete the install live
outside of promote starting on page UG 2-37 in the Aldon LM(i)
Users Guide.
See the online help text for information regarding the installation method
values available. For more information on specifying installation methods
the, see Defaults for Installation, starting on page DS 6-8.
To change install live data conversion specifications

Prerequisite

UG 2-32 in the Aldon LM(i) Users Guide. At step Step 5 on
page UG 2-33, be sure to type 4 (Change data conversion
specifications).
5 on page UG 2-36, in the Data conversion specifications field, be
sure to type Y (Yes).
When you press ENTER, the Specify Data Conversion panel displays:
CSPCLIVCNV
Specify Data Conversion
Release . . .
Environment .
Defaults:
CPYF FMTOPT
Retain saved
Position to .
. . . :
. . . :
DOUGS/DMS01/DELTA
PDN
. . . :
data :
. . . .
*MAP
N
Conversion program . :
*NONE
Library . . . . . :

CPYF opt (1=*DFT, 2=*MAP/*DROP, 3=*MAP, 4=*DROP, 5=*NOCHK, 6=*NONE, 9=*NOCPY)
Conversion: Program (*DFT, *NONE, name)
Library (*RCVLIB, *LIBL, name)
Retain (saved) data (Y=Yes, N=No, *=*DFT)
Object
PF
F3=Exit
Type
*FILE
CPYF
Opt
1
F5=Refresh
---- Conversion ----Program

Library
*DFT
F12=Cancel
Retn
Data
*
F22=More functions
At the Specify Data Conversion panel, modify values controlling

conversion of existing data at the targets into new file formats as
desired and press ENTER.
If you are installing live on promote, go to Step 6 on

page UG 2-34.
If you are installing live outside of promote, the Submit Job panel
displays. Go to To complete the install live outside of promote
starting on page UG 2-37 in the Aldon LM(i) Users Guide.
See the online help text for information regarding the data conversion
options available. For more information on data conversion, see Data
Conversion, starting on page CG 3-31, and Defaults for Data
Conversion, starting on page DS 6-7.
Requesting Install Live

Requesting install live places an install live request condition on an
object. The request condition specifies an object and environment for
which the object is to be installed live. A user with the necessary authority
can then complete the request by installing the object live for the
requested environment.
Objects Not Yet Eligible

It is possible to request install live of an object for an environment in
which the object is not yet available for install live. This most easily
happens when a new object is added to a release. The object becomes
available when it is promoted to or beyond the environment for which the
install live is requested. A request cannot be completed until the object is
available.
Objects Ineligible Due to Library Groups

It is also possible to request install live for an object that is not eligible for
install live because the library group or groups to which it is assigned are
not defined for deployment for the selected environment.
In such cases, fulfilling the install live request as if valid deletes the
request condition. Messages indicating that the object will not be installed
live display during the job definition process.
To request install live

Prerequisites
Configure install live for the release environments with which you
want work. See Configuring Install Live starting on page DS 7-2 in
the Aldon LM(i) Object Deployment Reference for details.
Establish user authorities. The user requesting install live must have
Request install live from... authority for the environment for which
they will request install live.
1. At the Aldon LM(i) main menu, type option 1 (Work with objects by
panel.
2. At the Work with Objects by Release panel, in the Opt field by each
object you want to install live, type option 57 (Request install live)
and press ENTER.
3. If objects of more than one release are selected for install live, the
Select Releases for Request Install Live panel displays:

CSELILVREL
Select Releases for Request Install Live
Objects have been selected for install live in the following releases.
Type default for the additional install live information.
Comment for log
. . . .
Type options, press Enter

1=Select for request install live
Opt
1
1
Release
DOUGS/DMS01/BASE
DOUGS/DMS01/DELTA
Command ===>
F3=Exit
F4=Prompt
Text
F9=Retrieve
F12=Cancel
F13=Repeat
The panel displays one record for each release containing objects you
selected for install live. On initial display, all releases are selected.
Press ENTER to continue.
If the Select Environments for Request Install Live panel does not
display, it means all objects are selected for install live for the same
environment.
4. If objects in the release you are working with can be installed live into
more than one environment, the Select Environments for Request

Install Live panel displays:
CSELILVENV
Release
Select Environments for Request Install Live
. . . . . . . . :
DOUGS/DMS01/BASE
The following environments are eligible for install live.

Type default for the additional install live information.
Comment for log
. . . .
Type options, press Enter

1=Select for request install live
Opt
Environment
ITG Integration
PDN Production
Only install live-defined environments presented for selection.

Command ===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F13=Repeat
The panel displays one record for each release environment

configured for install live.
In the Opt field by each environment for which you want to

request install live, type 1 (Select for request install live) and press
ENTER.
This panel does not display if only one environment of the release is
configured for install live.
5. The Request Install Live panel displays:
CRQSINSLIV
Request Install Live
Release . . . . . . . . :
ALDON/ACMSDEMO/BASE
QUA
Type the additional install live information below, press Enter.

Comment for log
. . . .
Objects selected for request install live:

Object
Type
Attribute
PGM11
*PGM
RPG
1 objects selected for request install live.

Command ===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F22=More functions
The release and environment for which you are installing live display
at the top of the panel. Objects you selected for install live from that
release environment are listed one per record in the lower portion of
the panel.
In the Comment for log field, type a comment for the development
and deployment logs.
6. Press ENTER.
Aldon LM(i) creates an install live request condition for each object
you selected.
If there are additional releases for which you selected objects, the
Select Environments for Request Install Live panel displays for
the next release. Go to Step 4 on page DO 3-35.
If the Work with Objects by Release panel displays, you are done
requesting install live for the selected objects.
Fulfilling Install Live Requests

To fulfill install live requests
Establish user authorities. The user fulfilling an install live request must
have Perform install live from... authority for the environment for which
they will fulfill install live requests.
1. At the Aldon LM(i) main menu, type option 4 (Conditions menu) and
press ENTER to display the Work with Requests and Non-Conflict

Conditions panel.
Objects with pending install live requests are identified by the code
combination R L in the Cnd column. The Condition Environment
column indicates the environment for which install live was
requested.
2. At the Work with Requests and Non-Conflict Conditions panel, in the
Opt field by each install live request you want to complete, type
option 47 (Install live) and press ENTER.
3. Continue with Step 3 on page UG 2-35 to complete submission of the
install live job.

Note
You can also fulfill install live requests from the Work with Objects by
Release and Work with Tasks panels. However, from these panels you
must use option 28 (Work with conditions...) to determine the release
environment for which the request is pending on an object.
Clearing Invalid Install Live Request Conditions

Users may sometimes create an install live request for an object for a
particular release environment that is not valid.
An object is eligible for install live for a given release environment if the
following conditions are met:
There must be a deployment profile of type live for the release
environment
There must be at least one target defined by a target definition of type
live associated with that deployment profile
The object, its source, or both must be associated with a library group
that is mapped to an install live library by the target definition
Aldon LM(i) does not check these conditions when users request install
live for an object. You will not be able to satisfy the request by installing
the object live until the conditions are met.
To prevent requests which cannot be satisfied from accumulating,
Aldon LM(i) automatically removes invalid requests when you attempt to
satisfy them. You attempt to satisfy install live requests by defining an
install live job. Either of the two methods of defining install live jobs may
be used to satisfy install live requests. SeeTo install live on promote on
page UG 2-32 in the Aldon LM(i) Users Guide and To install live
outside of the promote function on page UG 2-35 for more information.
Aldon LM(i) displays messages and warnings during the install live job
definition process so you will know that certain requests are being cleared
but not satisfied.
If you find that you are working with invalid requests while processing
requests, you can follow either of two courses of action:
You can proceed with the install live job definition process that results
in satisfying valid requests and clearing invalid requests
You can:
Back out of the job definition process by pressing F12 and/or F3
Configure install live definitions or change object library group

assignments to satisfy the requirements to make the requests valid,
then
Proceed to satisfy the requests
Changing conditions to satisfy requirements may involve one or more of

the following:
Modifying target definitions or object library group assignments so
that library groups containing the object and/or its source are mapped
to target libraries
Creating a Live deployment profile associated with Live target
definitions for the release environment for which the install live was
requested if one did not previously exist
You can also delete invalid install live requests using the Work with
Requests and Non-Conflict Conditions panel as described in Cnd
Column Codes: Requests, Acknowledgements, Failure, and Hold,
starting on page DO 5-5.
Changing an Objects Production Location

When adding or loading an object to the Aldon LM(i) database, it is
designated a library group for the object and/or a library group for the
source when applicable. The library groups define which library the
source and object resides in when promoted to the production
environment. If the object has source, you also have to define the names
of the source file and the member within that source.
The library groups are initially assigned when you:
Map or load a release
Add a new object to a release under development
Check out or create a non-resident object into a delta release from an
ancestor release.
Move/Define Object Function

You can use the Aldon LM(i) move/define function to reassign the
existing library groups (and therefore production locations) for an object
and its source or to define the library groups for the object and source in
descendant releases where the object is not currently resident. This
function can also be used to change the names of the source file and
source member.
If you need to deploy an object from a release where it is not resident and
the library group allocation is not *MAP or via a library group exit
program, you can use this option to define the library group for the
non-resident release.
How Aldon LM(i) changes Production Locations
If an object is currently resident in production when its library group is
changed the following actions occur:
If the new library group is associated with a different production
environment library, Aldon LM(i) moves the current production copy
of the object (and/or source) to the new production environment
library. Aldon LM(i) does not take any action on copies of the object
in data libraries or deployment targets, even though the move may
result in future updates of the object going to different data libraries. If
required, the existing copies of the object should be manually moved
to the new library.
When moving source Aldon LM(i) first copies the source member to
the new file, then removes it from its previous location. If the member
is to remain in the same file in the same library then a simple rename is
used.
Effects of changing an objects
Production location
Moving the object to a new library group may cause Aldon LM(i) to
update the object into different data libraries in data sets or deployments,
or completely stop updating data sets and deployments with the data
object. You must review the data set and deployment definitions to ensure
the object/source will in the future go to the correct library.
Authority requirements to use

the Move/Define function
From the Work with Objects by Developer panel you must have the
following authority:
For an object in Development, you must have Perform checkout
authority
For an object in any other active environment, you must have Promote
to... authority for that environment
From the Work with Objects by Release panel you must have the
following authority:
For an object that exists only in the Development environment, you
must have Perform checkout authority
For an object that exists in one or more controlled environments you
must have authority to Promote to... the highest environment in which
the object resides in that release. The highest environment is the
environment closest to the Production environment and inclusive of
the Production environment.
The object you want to move must be defined to the release you are
working with, but need not be resident or present in the Production
environment of an ancestor release.
The new locations you designate must be available as follows:
Library groups must be defined in the release
The source file need not exist; Aldon LM(i) creates it if necessary
The source member must not already be in use for another object in
the release in the selected source file
The source member must not be checked out to more than one
developer if you are changing its source file or source member name.
To move/define a single object

See Authority requirements to use the Move/Define function, starting on
page DO 3-39.
1. At the Aldon LM(i) main menu, do one of the following:
Type option 1 (Work with objects by release) and press ENTER to

display the Work with Objects by Release panel
Type option 2 (Work with objects by developer) and press ENTER

to display the Work with Objects by Developer panel
2. In the Opt field by the object you want to move, type 9
(Move/Define) and press ENTER to display the Move/Define Object

panel:
CMOVOBJ
Move/Define Object
Object . . . . . . . :
Release . . . . . . :
A
*PGM
DMS/DMS/DMS
Object
Object
Source
Source
1 first lg
DMSDMSPDN1
1 first lg
DMSDMSPDN1
library
library
library
library
group
. . .
group
. . .
:
:
:
:
Object attribute . . . :
Extended attribute . . :
CLP
OPM
Data option . . . . . :
Resident in release . :
Promote
Yes
To
To
To
To
object
source
source
source
library group
library group
file . . . . .
member . . . .
.
.
.
.
.
.
.
.
*SAME +
*SAME +
*SAME
*SAME
*SAME,
*SAME,
*SAME,
*SAME,
library group number

name
name
Command ===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F13=Move/define in descendent releases F15=Full name F22=More functions
3. At the Move/Define Object panel, in the To object library group
field, do one of the following:
To move the object to a new library group, type a new library

group number.
To leave the object in its current library group, accept the default
value, *SAME.
4. In the To source library group field, do one of the following:
To move the objects source to a new library group, type a new

To leave the objects source in its current library group, accept the
default value, *SAME
5. In the To source file field, do one of the following:
To move the objects source to a different source file, type a new

source file name
To leave the objects source in the current source file, accept the
6. In the To source member field, do either of the following:
To move the objects source to a different source member, type a

new source member name
To leave the objects source in the current source member, accept

the default value, *SAME
7. Press ENTER.
Aldon LM(i) changes the objects Production location as specified.
To move/define an object if descendent releases are

available
If descendent releases are available, F13 (Move/define in descendent
releases) displays on the Move/Define Object panel.
1. From the Move/Define Object panel, press F13 to display the Specify
Library Groups for Descendent Releases panel. This panel lists

descendent releases, allowing you to specify Library Group
assignments for descendent releases. The Move/Define Object in
Descendent Release panel displays.
CSELRELLGP
Specify Library Groups for Descendent Releases
Object . . . .
Object type .
Release . . .
Release level
Find release .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
.
AS
*VIEW
DOUGS/DMS/DMS
BASE
+ Name
SQL

2=Specify library groups
Opt
Descendent
Release
DMS2
DMS3
Lvl
1
2
Res
No
No
Object
LG Library
(not defined)
(not defined)
Source
LG Library
(not defined)
(not defined)
F3=Exit F11=View 2 F12=Cancel F15=Full name F22=More functions
2.
CMOVOBJDSC
Specify library groups for the object and press ENTER.

Move/Define Object in Descendent Release
Object . . . . . . . :
Release . . . . . . :
AS
*VIEW
DOUGS/DMS/DMS2
Object
Object
Source
Source
(not defined)
library
library
library
library
group
. . .
group
. . .
:
:
:
:
SQL
(not defined)
Data option . . . . . :
Resident in release . :
Promote
No

Attempt map first . . . . .
To object library group . .
To source library group . .
Command ===>
F3=Exit
F4=Prompt
F22=More functions
Y
*SAME +
*SAME +
F9=Retrieve
Y=Yes, N=No
*SAME, library group number
*SAME, library group number
F12=Cancel
F15=Full name
To move a group of objects

This procedure can also be used to define library groups for a group of
non-resident objects in a child release.
See Authority requirements to use the Move/Define function, starting on
page DO 3-39.
panel.
2. At the Work with Objects by Release panel, in the Opt field by each
object you want to move, type 29 (Move (library groups)) and press
The Move/Define Objects (Library Groups) panel displays:
ENTER.
CMOVOBJLGP
Release
Move/Define Objects (Library Groups)
. . . . . . . . . . :
DOUGS/DMS01/DELTA
Type the additional move information below, press Enter.

For non-resident objects,
attempt map first . .
To object library group .
To source library group .
Print report . . . . . . .
Run option . . . . . . . .
.
.
.
.
.
Y
Y=Yes, N=No
*SAME + *SAME, library group number
*SAME + *SAME, library group number
N
Y=Yes, N=No
1
1=Run interactively, 2=Run in batch
Objects selected for move (library groups):

Extn Dta
Object
Type
Attribute Attr Opt
LF
*FILE
LF
No
MODULE2
*MODULE RPGLE
No
PF
*FILE
PF
Yes
F3=Exit
F4=Prompt
F12=Cancel
Res
No
Yes
Yes
Object
Source
LG Library
LG Library
01 DS1DSDPDN1 01 DS1DSDPDN1
F22=More functions
The lower portion of the panel lists all objects selected for the move.
The LG fields display current library group assignments for each
object and its source.
3. At the Move/Define Objects panel, in the To object library group
field, do one of the following:
To move the object to a new library group, type a new library

group number
To leave the object in its current library group, accept the default
value, *SAME
4. In the To source library group field, do one of the following:
To move the objects source to a new library group, type a new

To leave the objects source in its current library group, accept the
5. In the Print move report field, do one of the following:
Type Y (Yes) to print a report describing the move action
Type N (No) to suppress report printing
6. In the Run option field, do either of the following:
To run the job interactively, type 1 (Run interactively)
To run the job in batch mode, type 2 (Run in batch)
7. Press ENTER.
Aldon LM(i) changes object Production locations as specified.
Modifying and Testing ILE Objects

Modifying and Testing ILE Modules
To make modifications within the modules on which an ILE program is
based, check out the ILE program along with the desired modules and
change the modules in Development. To avoid incrementing version
numbers for the unchanged ILE program, delete the copy in Development
after testing there is complete and recreate the ILE program as a
non-resident object in next testing environment instead of promoting it
from Development.
If splitting a module referenced in a binding directory into two modules,
checkout the binding directory referencing the module for modification as
well.
Modifying and Testing ILE Programs

To change the list of modules on which an ILE program is based, check
out the ILE program and any binding directories to be modified. Change
creation defaults recorded in the Aldon LM(i) database for the object
using option 15, Change create options, on the Work with Objects by
Release or Work with Objects by Developer panels. Create the program
with Aldon LM(i) option 14. Creation via option 14 creates the object
using creation parameters modified with option 15 in the previous step.
If you check out an ILE program with its modules, be sure to promote
both the ILE program and the changed modules it uses together. If you do
not promote the changed modules, Aldon LM(i) creates the ILE program
over obsolete copies of the modules accessed through the object creation
library list for the receiving environment.
Retiring Objects
Most types of objects can now be retired. You can retire an object by
checking it out to the development environment, using option 25 (Retire)
from the Work with objects by Release or Work with Objects by
Developer panels.
Retire object flags the object so that, as it is promoted or deployed, the
target object is made inaccessible. When an object is retired, any other
version of the object existing in a later environment or an ancestor release
becomes invisible during execution. For more information, see Retiring
Objects on page UG 5-12 in the Aldon LM(i) Users Guide.
Cancelling Checkouts and Deleting Objects

You can delete an object that is no longer required in a given environment
with option 4 (Delete) on the Work with objects by Release, Work with
Objects by Developer, or Act upon Dependent Objects panels. Delete an
object from a release by deleting all copies of the object in all
environments. Deletion of the last copy of an object in a release also
deletes all copies of the object archived for that release from the
application's Archive library. After deletion of the last copy of an object in
a release, there will be no copies of the object or associated source for the
object anywhere within Aldon LM(i) for that release. Log entries for the
object are preserved. Copies of the object in other releases of the
application are not effected. If the object was associated with a task at
checkout using the For Task field on the Work with Objects by Release
panel, deleting it cancels the association with the task.
To delete an object from Development you must have OS/400 authority to
the developer library and object. To delete an object from Integration you
must have Perform promotion to Integration authority. To delete an
object from QA you must have Perform promotion to QA authority. To
delete objects from Production you must have Delete production
objects authority.
CDLTOBJREL
Confirm Delete of Objects
Warning! Before pressing Enter to confirm your choices for 4=Delete, consider
that deleting the last copy of an object within a release also deletes the
Archive copies for that release. If more than one copy of the object is
eligible for deletion, an additional panel will display allowing selection
of the specific environments from which to delete copies of the object.
Type choices and press Enter to confirm your selections for 4=Delete.
Press F12=Cancel to return to change your selections.
Select for delete from environments
Run option . . . . . . . . . . . .
Opt Object
4 CLNADR
Type
*FILE
F10=View 3
Attribute
PF
F11=View 2
*SBS
1
D Release
ACM/BAS
F12=Cancel
*SBS, *ALL, D/I/Q/P

2=Run in batch
Envs
D QP
Rl T Cnds
Chkout Dvp.
MARKE
F15=Full name
Figure 17 - Confirm Delete of Objects Panel
Initial selection of an object for deletion displays the Confirm Delete of

Objects panel shown in Figure 17. The exact panel displayed depends on
the panel from which the function is called.
If the record selected for deletion represents copies of the object in several
environments, pressing Enter from the Confirm panel displays a second
panel allowing selection of the copy or copies you wish to delete.
CSELDLTOBJ
Select Copy of Object to Delete
Object . . . . . . . . . :
Object type . . . . . . :
Release . . . . . . . . :
CLNADR
*FILE
ALDON/ACMSDEMO/BASE
Copy of object to be deleted not known for the above object.

Select zero or more copies, press Enter.
Press F12=Cancel to return and not delete objects.
1=Select
Opt
Attribute
PF
PF
Environment
DVP MARKE
QUA
Library
MARKE
ACQUAL
3 objects selected for delete.

F12=Cancel
F22=More functions
Figure 18 - Select Copy of Object to Delete Panel
Deleting Archived Objects

To delete a copy of an object from the archive, place a 4 by the
corresponding entry on the Work with Archive Object panel (accessed via
option 3 Work with archive objects on the main Aldon LM(i) menu).
Work with release definition authority is required to delete an archive
copy of an object.

Daily Operations
DO
Chapter 4
Working with Objects
This chapter discusses the following topics:

Working with Objects by Developer on page DO 4-2
Creating Objects on page DO 4-4
Changing an Object Description on page DO 4-9
Adding an Object on page DO 4-13
Single-Copy Create Specifications on page DO 4-16
Working with Object Dependencies on page DO 4-18
Completing Object Dependency Data for ILE Objects on page DO 4-20
Using Object Dependency Data on page DO 4-25
Using the Development Log on page DO 4-32
Online Help Text
help text.
Working with Objects DO 4-1
Working with Objects by Developer

Libraries and objects in Development environments are outside of the
Aldon Lifecycle Manager for System i (Aldon LM(i)) control system.
Aldon LM(i) records movement of an object to a specific development
library, and will accept it back into Aldon LM(i) only from the library in
which it was placed. Beyond this, developers are free to work with objects
using the tools and techniques to which they are accustomed. The Work
with Objects by Developer panel, shown in Figure 19 through Figure 22,
also provides access to common development functions, as well as
Aldon LM(i) specific functions. View 4, which is not shown, displays
descriptive text for each object.
CWRKOBJDVP
Position to
Work with Objects by Developer

. . . . . . .
__________

2=Edit source
3=Check out* 4=Remove(cancel chk)
7=Promote*
14=Create*
(*=Combined job)
5=Browse source
17=Request promote ...
More:
+
Checkout
Oth
D Release E Developer Env T Requests
Cn
G75/BS1
DALEA
DVP
D75/BAS
DALEA
DVP
G75/BS1
DALEA
D**
G75/BS1
JUDYS
DVP
K G75/BS1
JUDYS
QUA
B75/BAS
TONYS2
QUA
G75/TD1
TONYS
DVP
B75/BAS
TONYS2
QUA
D75/DL1
CATHYC
DVP
K G75/BS1
JUDYS
QUA
Opt Object
Type
Attribute
@_070213
*DTAARA
@_610_DTA
*DTAARA
@_610_DTA
*DTAARA
@A
*PGM
RPG
@NEWFILE
*FILE
PF
ABCSQLRPG
*PGM
SQLRPGLE
ABCSQLRPG
*SQLPKG PACKAGE
ABCSQLRPG
*SQLPKG PACKAGE
ACTGLL
*FILE
LF
ACTGLP1
*FILE
PF
Command ===> _________________________________________________________________
F3=Exit
F4=Prompt
F5=Refresh
F10=View 3
F11=View 2
F12=Cancel
F19=Work with objects
F23=More options
F24=More keys
Figure 19 - Work with Objects by Developer Panel, View 1 of 4

CWRKOBJDVP
Position to

. . . . . . .
__________

6=Print source
19=AltEdit
(*=Combined job)
28=Work with conditions ...
Opt
__
__
__
__
__
__
__
Release
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
Object
CLNADRL
CLNADRL
CLNADRL
DEMOCBL1
DEMOCBL1
DEMOCBL2
DEMOCBL3
Type
*FILE
*FILE
*FILE
*PGM
*PGM
*PGM
*PGM
Env
DVP
DVP
QUA
DVP
QUA
DVP
QUA
Version
00100002
00100003
00100001
00100002
00100001
00100001
00200001
Lvl
BASE
BASE
BASE
BASE
BASE
BASE
BASE
Command ===> _________________________________________________________________
F6=Add object
F7=Add task
F14=WRKSBMJOB
F15=Full name/fold
F17=Subset
F18=WRKSPLF
F22=More functions
F24=More keys
DO 4-2 Working with Objects
CWRKOBJDVP
Position to

. . . . . . .
__________

(*=Combined job)
9=Move/define
10=Specify data conversion
16=Change
18=Work with tasks
21=Assign tasks*
22=Remove task assignments ...
Opt
__
__
__
__
__
__
__
Object
CLNADRL
CLNADRL
CLNADRL
DEMOCBL1
DEMOCBL1
DEMOCBL2
DEMOCBL3
Type
*FILE
*FILE
*FILE
*PGM
*PGM
*PGM
*PGM
Env
DVP
DVP
QUA
DVP
QUA
DVP
QUA
Object
Library
MARKE
PHILV
ACQUAL
MARKE
ACQUAL
MARKE
ACQUAL
------------- Source ------------Library

File
Member
MARKE
QDDSSRC
CLNADRL
PHILV
QDDSSRC
CLNADRL
ACQUAL
QDDSSRC
CLNADRL
MARKE
QCBLSRC
DEMOCBL1
ACQUAL
QCBLSRC
DEMOCBL1
MARKE
QCBLSRC
DEMOCBL2
ACQUAL
QCBLSRC
DEMOCBL3
Command ===> _________________________________________________________________
F9=Retrieve
F13=Repeat
F21=Print
F24=More keys

CWRKOBJDVP
Position to

. . . . . . .

20=Scan for requisite objects*
32=Change create overrides
(*=Combined job)
25=Retire
26=Transfer*
30=Display log
39=Display requisite objects ...
More:
Opt
__
__
__
__
__
__
__
Object
CLNADRL
CLNADRL
CLNADRL
DEMOCBL1
DEMOCBL1
DEMOCBL2
DEMOCBL3
Type
*FILE
*FILE
*FILE
*PGM
*PGM
*PGM
*PGM
Text
CLNADRL Logical File
COBOL DEMO Program COBOL DEMO Program COBOL DEMO Program COBOL DEMO Program -
for Aldon/CMS Demo

for Aldon/CMS Demo
for Aldon/CMS Demo
Main Module
Main Module
1st Subordinate Module
2nd Subordinate Module
Command ===> _________________________________________________________________
F9=Retrieve
F13=Repeat
F21=Print
F23=More options
F24=More keys
Figure 22 - Work with Objects by Release Panel, View 4 of 4
With default subsetting, the Work with Objects by Developer panel

displays one record for each active copy of all objects in Aldon LM(i). An
object is active if it is in the Development, Integration, or Quality
Assurance environments. Subset the panel with F17 and F22 to focus the
display on a single application, release, task, developer, object type, and
so on. The sample panels are subset for the Base release of the
ACMSDEMO application. Some options on this panel are also available
from the more general Work with Objects by Release panel. (See Option
Processing for Sub-Files (Lists) on page DO F-11 for information on
*=Combined job options, such as 7 (Promote), and the processing of
multiple non-combined job options as a group.)
See the online help text for this panel for descriptions of all available
options and function keys.
Creating Objects
Uses of Create Function
In Development, create objects to recompile changed source

Outside of Development,
Recreate unchanged dependent objects when the objects they

reference change. For example, if a Production file changes, you
may want to recreate the programs that use it.
Maintain test and Production environments as file layouts change.

For example, when you promote a changed file layout to QA, you
do not want to recreate the dependent programs in Production.
Instead, you can use the create function to create new copies in the
QA environment over the new file layouts.
Obtain resident copies of objects needed in an environment for

other testing reasons
Resident Object
A resident object is an object that currently exists in the specified

environment.
Non-Resident Object
A non-resident object is an object that is defined to the release or one of

the releases ancestors, but that is not currently present in the specified
release environment.
Eligible Objects
You can create:

Any resident source-based object in any Aldon LM(i) environment
Any non-resident objects into Integration, Quality Assurance, or the
Production environment of a delta release
(Creation of a resident non-source object is not allowed because the
create has no effect.)
Testing and Non-Resident

Object Creation
Testing of an object in an environment may require creating resident

copies of non-resident objects using the create non-resident option. For
example, testing a changed file requires recompiling the programs that
use that file to avoid level checks, which changes the status of these
programs in the testing environment from non-resident to resident.
Phantom objects are also considered non-resident even though they have
been created in the environment by Aldon LM(i).
Flow for Object Creation
Creating a resident object in place does not result in object movement.
How Aldon LM(i) creates a non-resident object into a given

environment
1. Selects the next available copy of an object as a model using the
object creation library list

2. Copies source for that copy to the target environment
3. Recompiles the object in the target environment from that source
For a discussion of Aldon LM(i) object creation library lists see Library
Lists starting on page CG 1-1 in the Aldon LM(i) General Topics
Reference.
Creation of a non-resident object makes that object resident in the
selected environment. You can then promote or delete the object from the
environment like any other object.
Version Numbers of Objects
Made Resident
Because the created copy did not pass through Development and was not
changed, the created copy has the same Aldon LM(i) object version
number as the model upon which it is based.
Create With or Without Task

Association
A task identifier is always optional for a create. Users with Change task
definition authority can add objects to an existing task or define a new
task when performing a create. For users without this authority, the object
must already be included in the task they enter on the create panel.
Object Dependency Data
Aldon LM(i) captures object dependency data when creating objects to

ensure the accuracy of object dependency data. Aldon LM(i) also uses
object dependency data to create objects in the correct order when a create
job includes multiple objects.
Data in Data Sets
When you create a logical file or physical file, Aldon LM(i) copies the file
format into:
Each data set associated with the receiving environment
Each data set associated with environments further from Production
that does not contain a more recently modified copy of the file.
If a previous copy of the file exists in a data set, Aldon LM(i) saves the
old copy, replaces it in the data set with the new file description, then
copies any data in the old version of the file into the new description. See
Data, Data Libraries, and Data Sets starting on page CG 3-1 in the
Aldon LM(i) General Topics Reference for more information.
Effect of Pending Conditions on

Creation
Pending conditions on an object do not inhibit object creation.
Eligible Agents: Authority to

Create Objects
A user must have Perform promotion to... authority to an environment

to create objects in that environment.
Automatic Create Command

Selection
Aldon LM(i) selects the correct IBM or user-defined create command and
options for each object based on the object's type, attribute, and
Aldon LM(i) database entry. See Object Creation, starting on page
DO 1-12, Single-Copy Create Specifications, starting on page DO 4-16,
and Custom Object Creation Setup starting on page SA 23-1 in the
Aldon LM(i) Setup and Administration Reference for more information
on create commands and create command selection.
Automatic Create on Promote
With selection of the appropriate release setup option, Aldon LM(i)

automatically creates objects on promotion into a new environment.
You can create objects outside of the promote function using:

The Create Objects panel discussed below and in Creating Objects
starting on page UG 2-15 in the Aldon LM(i) Users Guide
Option 14, Create, is available on the Work with Objects by Release,
Work with Developer Objects, Act upon Dependent Objects, and Work
with Tasks panels.
The ACMSCREATE command discussed in ACMSCREATE
Command Syntax starting on page CG 7-10 in the Aldon LM(i)
General Topics Reference
Aldon-supplied PDM user options discussed in PDM-Style User
Options on page DO D-1 in the Daily Operations Reference For
System i Servers
To create resident objects

See To create an object in an active environment starting on page
UG 2-19 in the Aldon LM(i) Users Guide.
To create non-resident objects

1. At the Aldon LM(i) main menu, type option 1 and press ENTER. The
Work with Objects by Release panel displays.

Tip
You can also select objects for non-resident creation by selecting a task
with option 14 on the Work with Tasks panel.
2. In the Opt field, by one or more objects, type 14 (Create) and press
ENTER.
The Create Objects panel displays:

CCRTOBJ
Create Objects
Type the additional create information below, press Enter.

Create in environments . . . .
Objects with residence status
Based on residence status . .
For task . . . . . . . . . . .
Stop upon failure . . . . . .
Print compile listing? . . . .
Do you wish to specify
data conversion methods .
Change Analyzer options . . .
.
.
.
.
.
.
.
.
.
.
.
.
. .
. .
*SBS
3
1
Y
N
*SEL, *SBS, *ALL, D/I/Q/P

1=Both, 2=Res, 3=Non res
1=Now, 2=At run time
+ Name
Y=Yes, N=No, R=*REL
Y=Yes, N=No, R=*REL
N
N
Y=Yes, N=No
Y=Yes, N=No
Objects selected for create:

Object
DEMOCBL1
DEMOCBL3
Type
*PGM
*PGM
Attribute
CBL
CBL
Release
ACM/BAS
ACM/BAS
Environments
DVP
ITG QUA PDN
DVP MARKE
ITG QUA PDN
(ITG)(QUA) PDN
2 objects selected for create.

F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F20=Enlarge list
F10=View 3
F11=View 2
F22=More functions
3. In the Objects with residence status field, do one of the following:
Type 3 to create only non-resident objects.
Type 1 to create both non-resident and resident objects.
4. Complete other values on the panel as desired.
If the residence status of objects in target environments is likely to

change between the time you complete this panel and the time the
create job runs, you may wish to type 2 in the Based on residence
status field to defer checking of residence status until the job actually
runs. This allows you to more effectively control modification of
environments with multiple step procedures involving multiple jobs.
Note
5. Press ENTER to submit the create job.
To create *CMD objects in Development

Prerequisite
Aldon LM(i) creates *CMD objects in Development, but you must first
identify the command processing program using option 15 (Change create
options) (See Single-Copy Create Specifications, starting on page
DO 4-16 for more information.)
After identifying the command processing program, create the *CMD
object by selecting it with option 14 as described in Creating
Objects on page UG 2-15 in the Aldon LM(i) Users Guide.
To prepare to create a logical file with fields defined by

reference
By default, Aldon LM(i) creates logical files in alphabetical order. This
results in incorrect creation of a logical file with fields defined by
reference to another logical file if the referenced file comes later
alphabetically than the referencing file.
To allow Aldon LM(i) to correctly create the referencing logical file,
create manual object dependency records for the referencing logical file
with the following procedure:
1. At the Work with Objects by Developer or the Work with Objects by
Release panel, in the Opt field by the referencing logical file, type 40
(Define requisite objects) and press ENTER.
The User-Defined Requisite Objects panel displays. (See To
manually specify object dependencies on page UG 2-41 in the
Aldon LM(i) Users Guide.)
2. Do the following for each referenced logical file:
a.
In the Requisite Object Name and Type fields, type the name
of the referenced logical file and *FILE.
b.
Use the Create Dependent field, type Y.
3. If you accessed this panel from the Work with Objects by Release
panel, use F8 (Next environment) and F7 (Previous environment) to

move between copies of the object in different Aldon LM(i)
environments. Complete a requisite objects list for each copy of the
logical file.
4. Press ENTER to load the defined relationships into the Aldon LM(i)
object database.
Note
You can also create manual object dependency records using the
command interface. See Overview: Object Dependency Commands
starting on page CG 7-25 in the Aldon LM(i) General Topics Reference
for more information.
Object Creation and ILE

Aldon LM(i) includes create command definitions for all ILE object
creation commands at installation. See Custom Object Creation Setup
starting on page SA 23-1 in the Aldon LM(i) Setup and Administration
Reference for details on object creation commands. Aldon LM(i) uses
the same object creation library lists for ILE objects as for other object
types. See Library Lists starting on page CG 1-1 in the Aldon LM(i)
General Topics Reference for a discussion of object creation library lists.
Aldon LM(i) selects modules and binding directories used by an ILE
program from the first environment containing them within the library
list. Aldon LM(i) constructs the library list based on the environment in
which the ILE program is created.
Changing an Object Description

Aldon LM(i) uses a special Aldon LM(i) extended attribute to select
handling procedures appropriate for each type of program object. Possible
extended attribute values are:
Extended attribute field
OPM Original Program Model This value instructs Aldon LM(i)

to create a program object using a traditional CRTxxxPGM command
which does not make use of any IBM Integrated Language
Environment (ILE) features.
BND Bound This value instructs Aldon LM(i) to create a partial
ILE program object with a CRTBNDxxx command which makes use
of some ILE features.
ILE Integrated Language Environment This value instructs
Aldon LM(i) to create a full ILE program object by linking one or
more *MODULE objects with the CRTPGM command. Create
*MODULE objects from source as a separate step with option 14
(Create). ILE program objects are non-source objects.
Source option field
The Source option field indicates whether the object is associated with
source, pseudo source, or no source. If the object is associated with source
or pseudo-source, the file and member containing the source or
pseudo-source display. If no source is associated with the object, these
fields are blank.
Pseudo source
Pseudo source refers to members containing CL commands which, when

executed, create the desired object. In this documentation, source refers to
both standard compilable source code and pseudo-source. For further
discussion of pseudo-source, including information on creating
pseudo-source for an object, see Pseudo-Source on page DO A-1.
Note
If you change the source file for a checked out object, but then cancel the
checkout using option 4 (Remove (cancel chk)), the source file change
remains in effect for any copies of the object in other environments of the
release. If you want to reverse the source file change, you must change the
source file back to the original before you cancel the checkout.
To change an object description

developer) and press ENTER to display the Work with Objects by

Developer panel.
2. At the Work with Objects by Developer panel, in the Opt field by the
object you want to change the description of, type 16 (Change object)
and press ENTER to display the Change Checked out Object panel:
CCHGOBJ
Change Checked Out Object
Object . . . . . . . . . :
DEMOCBL2
Release . . . . . . . . :
Developer . . . . . . . :
ALDON/ACMSDEMO/BASE
MARKE

Object type . . .
Object attribute .
Extended attribute
Data option . . .
Source option .
Source file .
Source member
Source library
For task . . . .
Comment for log
.
.
.
.
.
.
.
.
. . .
. . .
. . .
group
. . .
. . .
. : *PGM
.
CBL
.
OPM +
.
*
:
:
:
:
.
.
1
QCBLSRC
DEMOCBL2
3
+ Attribute
Extension
1=Keep destination data,
2=Promote data, *=Default
1=Source, 2=Pseudo source, 9=None
+ Name
_________________________________________________
Command ===> __________________________________________________________________

F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F22=More functions
Figure 23 - Change Checked Out Object Panel

Note
This panel displays the object name, release, developer to whom the
object is checked out, object type, attribute, the extended attribute (for
programs), and data option.
Associating Source with an Object

To associate source or pseudo-source with an object
1. Complete the steps in To change an object description, starting on
page DO 4-9.
2. At the Change Checked Out Object panel, in the Source option field,
do one of the following:
To associate standard source with the object, type 1 (Source)
To associate pseudo-source with the object, type 2

(Pseudo-source)
3. In the Source file, and Source member fields, type the names of the
file, and member containing the source or pseudo-source for the

object.
4. In the Source library group field, specify the library group number
for the library group to contain the objects source.

Note
You can place the cursor in this field and press F4 (Prompt) to select a
library group from a list.
5. Press ENTER to associate the source with the object.
If there is more than one library in your Production environment, libraries

do not display on the bottom of this panel, but an additional panel appears
on which you can specify the destination library for the source.
Changing Object Attributes

The Change Object Description panel can also be used to change the
attribute of an object so that the appropriate create command is used. For
example, to create RPT programs, change program object attributes from
RPG to RPT. The same effect can be achieved by defining object creation
defaults for objects, but changing the attribute has the added benefit of
making the nature of the object clear on display panels.
Moving to ILE
Aldon LM(i) supports conversion of programs from the original program
model to partial ILE and to full ILE.
To convert a program to ILE

Define the program to Aldon LM(i).
Prerequisites
Check the object out to Development.

Make whatever changes are necessary in the program source code.

Developer panel.
program you want to convert, type 16 (Change checked out object)

and press ENTER to display the Change Checked Out Object panel
shown in Figure 23 on page DO 4-10.
3. At the Change Checked Out Object panel, in the Object attribute
field, type the new object attribute.

You can place the cursor in the Object attribute field and press F4
(Prompt) to select the appropriate attribute from a list.
Note
4. In the Extended attribute field, do one of the following:
To change a BND program to ILE, type ILE

Go to To complete conversion to ILE on page DO 4-12.
To change an OPM program to BND, type BND
5. Press ENTER.
Aldon LM(i) changes the extended attribute of the program.
To complete conversion to ILE

This procedure describes how to use the Define Module Object panel to
associate existing source for a *PGM converted to ILE with a *MODULE
object.
Aldon LM(i) does not change or delete the actual source previously
associated with the OPM or BND program; the source remains in its
original location in your developer library.
Complete the steps in To convert a program to ILE on page DO 4-11.
In Step 4, in the Extended attribute field, be sure to type ILE.
Prerequisites
1. At the Change Checked Out Object panel, in the Source option field,
type 9 (No source).

2. Press ENTER to display the Define Module Object panel:
CDFNMDLOBJ
Define Module Object
Release . . . . . . . .
From source for program
From source file . . . :
From source member . .
Developer . . . . . . .
:
:
:
:
ALDON/ACMSDEMO/BASE
DEMORPG3
QRPGSRC
DEMORPG3
MARKE
The existing source for the above program may be use for a *MODULE object.
Select action
. . . . .
Module . . . . . . .
If 2=Add new *MODULE:
Module attribute . .
Source file . .
Source member .
Task . . . . . . . .
Comment for log . .
. .
.
.
.
.
.
.
.
.
.
.
+
RPG
*SYSOBJNAM
+
1=Copy source to existing *MODULE.

2=Add new *MODULE (copy source )
9=None
Name
Attribute
Name
Name, *SYSOBJNAM
Name
Command ===>
Figure 24 - Define Module Object Panel

Note
Information regarding the program source for the program converted to

ILE displays at the top of the panel.
3. At the Define Module Object panel, in the Select action field, do one
of the following:
To copy the source to an existing *MODULE, type 1 (Copy

source to existing *MODULE)
To add a new *MODULE and copy the source into it, type 2 (Add
new *MODULE (copy source))
To convert to ILE without associating the program source with a

*MODULE, type 9 (None)
4. If, in the Select action field, you typed 1 (Copy) or 2 (Add), in the
Module field, type the name of the module to receive the source for
the program.
5. If, in the Select action field, you typed 2 (Add), then in the Module
attribute, Source file, and Source member fields, type the attribute
source file, and source member names for the new module.
6. Press ENTER to confirm your entries.
To Change an Object From BND Back to OPM

To change an object back to extended attribute OPM from extended
attribute BND, load or map the object again as described in Mapping a
Release, starting on page SA 16-1 and Loading a Release, starting on
page SA 17-1.
Adding an Object
When to Add an Object
If a developer creates a new object, define it to Aldon LM(i) before
promoting it from the Development environment. An object need not exist
at the time it is added.
Interfaces Available
Add a new object using the Add Release Object panel or the
ACMSADDOBJ command discussed in The Add Object Command on
page CG 7-12. If you are modifying objects from a third party software
vendor and have chosen not to define the vendor's base release to
Aldon LM(i), you may wish to use the ACMSCHKFRN command to
simultaneously add and check out objects from the vendor base release.
See the section The Check Out Foreign Object Command starting on
page CG 7-8 in the Aldon LM(i) General Topics Reference for details.
Authority Required
You must have Perform checkout authority to add a new application
object.
Adding Objects with the Panel Interface
Press F6 to add a new object from the Work with Objects by Release
panel shown in Figure 7 on page DO 2-6, or from the Work with Objects
by Developer panel shown in Figure 19 on page DO 4-2. See Adding an
Object starting on page UG 5-2 in the Aldon LM(i) Users Guide for
details on adding an object with the panel interface.
Specifying a Developer
Specify the name of the developer definition for the developer adding the
new object. When you promote the object from Development,
Aldon LM(i) moves source from the source library named in this
developer definition. If you directed Aldon LM(i) to re-create objects on
promotion from Development, Aldon LM(i) deletes the object from the
developer's object library on promotion. If you direct Aldon LM(i) to
move the existing object forward with the source, the object will be
moved from the developer's object library to the new environment.
Unique Object Name/Type Required
Specify the name, type, and attribute of the object. The object name and
type together must be unique within a given application.
Object Source Identification
Specify the location of the associated source. If no source is associated
with the object type 9 for Source option. If pseudo-source is provided,
type 2. If standard source is provided, or the object is a records object
(Aldon defined type *RCDS) type 1. See Record Objects starting on
page DO C-1 for more information on defining *RCDS objects.
Identifying the Program Model
For program objects, specify the extended attribute. Aldon LM(i) uses the
extended attribute to select handling procedures appropriate for each type
of program object. Possible extended attribute values are:
OPM Stands for Original Program Model. This value instructs
Aldon LM(i) to create a program object using a traditional
CRTxxxPGM command which does not make use of any IBM
Integrated Language Environment (ILE) features.
BND This value instructs Aldon LM(i) to create a program object
with a CRTBNDxxx command which makes use of some ILE features.
ILE This value instructs Aldon LM(i) to create an ILE program
object by linking one or more *MODULE objects with the CRTPGM
command. Create *MODULE objects from source as a separate step
via option 14=Create. ILE program objects are non-source objects.
Data Option
The object data option allows objects to be promoted with or without their
data. The data option is set for each object and determines whether the
data in the from environment replaces data in the target library when the
object is promoted or deployed.
Keep destination data For objects with this setting, data in the
target library is preserved when a new copy of the object is promoted,
updated in a data set library, or deployed. CPYF or a user defined
conversion program is used to copy data from the old copy of the
object to the newly created one. This is the default setting for physical
files and SQL table objects.
The Keep destination data value is not allowed for logical files, views,
indexes, aliases, triggers, and constraints.
Note
Promote data For objects with this setting, data in the from
environment is copied forward to the target library with the newly
formatted object. Data is copied to controlled environment, data set
and target libraries. This option is used for physical files or tables that
are used to control how the application functions. This data is updated
by developers when functional changes are required and not by users
on a daily basis. Examples of files that are changed in this way include
tax tables, actuarial tables for insurance applications, and control files.
At checkout time the file definition and the data are copied to the
developer's library. At the time of promote, data is copied forward into
the next environment as well as into the associated data sets and
targets. While the table or file is in development, changes can be made
to both its layout and to its data. These changes can be promoted and
deployed together. Files that are checked out and promoted with data
can be defined with or without source and can have logical files, views
or indexes built over them. The logical files, views or indexes are
automatically re-created whenever the designated physical file or table
changes.
*RCDS objects cannot be over a physical file with Data option value
of 2 (Promote data).
Note
* indicates that the default value for the object type/attribute is to be

used. Physical files and tables default to 1 (Keep destination data).
Objects with any other type/attribute combination default to 2
(Promote data).
Task Association
To include the object in an existing task, type the task name. To associate
the object with a new task, press F7. Press F4 to prompt for a list of values
allowed for any field followed by a + sign. Type a comment describing the
add operation for the development log.
Multiple Library Groups
If you are using multiple library groups, when you press ENTER from the
Add Release Object panel, two additional panels display. On the first
panel, select one of your library groups to receive the object from the final
promotion. On the second panel, specify the library group to receive the
object's source member.
Special Object Types

See Record Objects starting on page DO C-1 for more information on
defining *RCDS objects. See Menus as Aldon LM(i) Objects, starting
on page DO B-1 for information on defining menus to Aldon LM(i). See
index entries under ILE for additional information on working with ILE
objects.
See Adding SQL Objects, starting on page DO G-2 for more
information on adding SQL objects.
Single-Copy Create Specifications

Aldon LM(i) creates objects like the existing copy in the same
environment or like the first copy found using the object creation library
list unless instructed to do otherwise by a single-copy create specification,
or a release-, application-, or global-level create command default.
For many purposes, a single-copy create specification is sufficient and
simpler. While it exists, a single-copy create specification supersedes all
command defaults that would otherwise apply to that copy. The
single-copy create specification travels with the copy of the object as it
moves through the release environments. If the copy is used to fulfill a
checkout, the single-copy create specification accompanies the copy to
Development. If a copy of the object remains behind in Integration or
Quality Assurance, a copy of the single-copy create specification remains
associated with that copy of the object as well.
See also the following topics:
For general information on create commands and create command
defaults, and information on working with create command defaults at
the global level, see Custom Object Creation Setup starting on page
SA 23-1 in the Aldon LM(i) Setup and Administration Reference
For information on working with command defaults at the application
level, see Application-Level Create Command Defaults starting on
page 12-10 in the
For information on working with create command defaults at the
release-level, see Release-Level Defaults for Object Creation
starting on page SA 22-7 in the Aldon LM(i) Setup and
Administration Reference
For a general discussion of Aldon LM(i) object creation, see Object
Creation on page DO 1-12.
To define a single-copy create specification

1. At the Aldon LM(i) main menu, do one of the following:
Type option 1 (Work with objects by release) and press ENTER to

display the Work with Objects by Release panel
Type option 2 (Work with objects by developer) and press ENTER

to display the Work with Objects by Developer panel
2. In the Opt field by the object for which you want to define create
specifications, type option 15 (Change create options) and press

ENTER.
The Change Object Creation Options panel displays:

CCHGCRT
Change Object Creation Options
Release . . . .
Object name . .
Object type . .
Object attribute
.
.
.
.
.
.
.
.
:
:
:
:
ALDON/ACMSDEO/BASE
DEMORPG4
Environment . . . . :
*PGM
Object library . . . :
RPG
DVP
MDEBSPDN1
OPM

Create command . . . .
Library . . . . . .
CRTCBLPGM
*LIBL
*SYS, command
*LIBL, library
Create options (Press F4 to prompt; type *DFT to reset to defaults):

GENOPT(*NOOPTIMIZE) USRPRF(*USER) TEXT('DEMORPG4 test program)
Command ===> _________________________________________________________________

F3=Exit F4=Prompt
F9=Retrieve
F12=Cancel
F15=Full name
Figure 25 - Change Object Creation Options Panel

3. In the Create command field type the name of the custom create
command to be used or *SYS to use the standard IBM create

command.
4. In the Library field, if you specified a value other then *SYS in the
Create command field, specify the library containing the create

command by doing one of the following:
Type *LIBL to search the library list
Type a specific library name.
5. In the Create keywords field, do either of the following:
Type the keywords and parameter values
Press F4 (Prompt) to display a prompt screen showing the

parameters for the specified command
6. Press ENTER.
7. If the Select Copy of Object for Change of Creation Options panel
displays, type a 1 (Select) by the copy or copies for which you want
to define create specifications. Press ENTER.
CSELCHGCRT
Select Copy of Object for Change of Creation Options
Object . . . . . . . . . :
Object type . . . . . . :
Release . . . . . . . . :
ACTGLL
*FILE
GARYM/GARYMAPP/BASE
Copy of object for change of creation options not known for the above object.
Select zero or more copies, press Enter.
Press F12=Cancel to return and not change creation options.
1=Select
Opt
Attribute
LF
LF
F3=Exit
Environment
QUA
PDN
F12=Cancel
Library
GM7BASQUAL
GM7BASPDN1
F15=Full name
Type
F22=More functions
Figure 26 - Select Copy of Object for Change of Creation Options panel
To delete a single-copy create specification

1. To delete a single-copy create specification, begin by following the
procedure described above in To define a single-copy create

specification starting on page DO 4-17 in the Aldon LM(i) Daily
Operations Reference. Perform steps 1 through Step 4.
2. When you get to Step 5, in the Create options field, type *DFT in
upper case and press ENTER.
Working with Object Dependencies

Use requisite/dependent object data to help determine the scope of tasks
and to facilitate recreating dependent objects to avoid level checks. For an
introduction to how Aldon LM(i) works with object dependencies, see
Working with Dependent Objects, starting on page UG 2-38.
When Aldon LM(i) Obtains Dependent Object Data
Aldon LM(i) obtains requisite/dependent object data:
When directed to scan objects during load, map, or copy procedures
At release activation
When adding objects
When creating objects
When promoting objects from local developers or between

Aldon LM(i) controlled environments (Note: Aldon LM(i) does not
scan for requisite/dependent object data when promoting from a
remote developer environment.)
When requested to do so for a release or for individual objects
From commands executed with data from third party software
Manually Specifying Object Dependencies
Use the panel interface or the ACMSUSRSCN command to directly
identify requisite/dependent object relationships, particularly those not
scanned by Aldon LM(i).
For more information on specifying with the panel interface
seeSpecifying Object Dependencies starting on page UG 2-41 in the
Aldon LM(i) Users Guide
See Overview: Object Dependency Commands on page CG 7-25 in
the Aldon LM(i) General Topics Reference for more information on
the command interface.
Manual Completion of Object Dependency Date for ILE Objects
Aldon LM(i) scans cannot determine all dependency information for
some ILE objects.
For information on manual completion of ILE dependency data see
Completing Object Dependency Data for ILE Objects, starting on
page DO 4-20.
How Object Dependency Data is Stored
A requisite/dependent object record moves with the copy of the object for
which it was created and also applies to new copies of the object created
by checkout. The Aldon LM(i) database maintains information
identifying the source of each object dependency record. The three
sources are:
Aldon LM(i) scans
Object dependencies identified manually by the user through the
Aldon LM(i) panel interface
Object dependencies identified by third party software and specified to
Aldon LM(i) through the command interface
You can specify dependency information for a given object using any or
all of these sources. When you request a list of objects dependent on or
requisite to a given object, Aldon LM(i) combines and presents the
information from all three sources.
To prevent the loss of dependency information, Aldon LM(i) replaces a
given type of object dependency record only with records generated in the
same manner.
Aldon LM(i) refreshes object dependency records produced by scanning

each time the object is recreated. The Aldon LM(i) database preserves
specified object dependency records and propagates them as new copies
of the object are created via checkout.
Each record includes the following information for an object:
Dependent object name, type, environment, and release
Date and time of last scan by Aldon LM(i)
Aldon LM(i) scan current flag
Requisite object name (first 10 bytes) and type
Requisite defined by flag
Create dependent flag
Recursive flag
Additional Information Regarding Acquiring Object Dependency Data
For additional information on:
Scanning objects during load, map, or copy procedures see
Population Functions Overview starting on page SA 15-1 in the
Aldon LM(i) Setup and Administration Reference
Scanning individual objects within a release and directly identifying
requisite/dependent object relationships, see Acquiring Object
Dependency Data, starting on page UG 2-39 of the Aldon LM(i)
User's Guide
Directly identifying requisite/dependent object relationships through
the command interface see Overview: Object Dependency
Commands starting on page CG 7-25 in the Aldon LM(i) General
Topics Reference
Completing Object Dependency Data for ILE Objects

Aldon LM(i) can scan ILE objects for dependency data during mapping
or loading, and later by request. From the scan, Aldon LM(i) can
determine the modules used to create an ILE program, but cannot
determine if modules for a given ILE program were specified directly in a
create command list or indirectly using a binding directory. Dependence
on a binding directory must therefore be specified manually. To provide
complete ILE object dependency data, perform the following steps:
*MODULE Manual dependency specification is usually not
necessary
*BNDDIR Manually identify *MODULE objects specified by a

binding directory as requisite objects for that binding directory using
the procedure described in To manually specify object dependencies
starting on page UG 2-41 in the Aldon LM(i) Users Guide.
Manually identify programs using a given binding as described in

To work with binding directory entries, starting on page
DO 4-21.
To identify programs using a given binding directory, select the

binding directories with option 45 (Assign binding directories) as
described in To work with binding directory entries, starting on
page DO 4-21
*PGM and *SRVPGM Programs may also be selected with option

45 (Assign binding directories) to identify binding directories used by
a given program as described in To work with binding directory
entries, starting on page DO 4-21
With requisite objects recorded and binding directory/program
relationships identified via option 45, Aldon LM(i) identifies the ILE
program as dependent on the modules it uses.
Working with Binding Directories

Use the Work with Binding Directories panel to associate binding
directories with ILE programs that use them. This information is
necessary to complete object dependency data for ILE programs that use
binding directories. Binding directories used by an ILE program cannot
be determined by scanning. Each record describes a previously defined
association between a binding directory and an ILE program.
To work with binding directory entries

At the Work with Objects by Release or Work with Objects by
Developer panel, in the Opt field by the ILE *PGM or *SRVPGM
object, or binding directory (*BNDDIR), type option 45 (Assign
binding directories) and press ENTER.
The Work with Binding Directories panel displays:

CWRKBNDDIR
Work with Binding Directories

4=Delete
Opt
Bind Dir
BNDDIR
BNDDIR
Pgm Name
ALDSCMAIN
ALDSRVPGM
Pgm Type
*PGM
*SRVPGM
Application
GARYM
GARYAPP
GARYM
GARYAPP
Subset: Rel:GARYM/GARYAPP/BASE Bnddir:BNDDIR

Command ===>
F3=Exit
F4=Prompt
F5=Refresh
F6=Add
F14=WRKSBMJOB
F17=Subset
F18=WRKSPLF
F21=Print
Release
BASE
BASE
F9=Retrieve
F12=Cancel
F22=More functions
Figure 27 - Work with Binding Directories Panel

Note
If entered by selecting an ILE program or service program, the panel lists

all binding directories associated with the selected ILE program. If
entered by selecting a binding directory, the panel lists all ILE programs
and service programs associated with the selected binding directory.
To add a binding directory entry

1. Display the Work with Binding Directory Entries panel as described
in To work with binding directory entries, starting on page

DO 4-21.
2. At the Work with Binding Directory Entries panel, press F6 (Add).
The Add Binding Directory Entry panel displays:

CADDBNDDIR
Add Binding Directory Entry

Release . . . . . . . :
Group . . . . . . :
BASE
GARYAPP
GARYM
Binding directory
BNDDIR
. . :
Program name . . . . . .
+ Name
Program type . . . . . .
*PGM, *SRVPGM
Command ===>
F3=Exit
F4=Prompt
F5=Refresh
F9=Retrieve
F12=Cancel
Figure 28 - Add Binding Directory Entry Panel

3. If the binding directory is identified in the Binding directory field,
do the following:
a.
In the Program name field, type the name of the ILE program
with which to associate the binding directory or press F4
(Prompt) to select the program name and type from a list
b.
In the Program type field, if it is not already completed, type

the type of the ILE program with which to associate the binding
directory
4. If the program name and type are identified in the Program name
and Program type fields, in the Binding directory field, type the
name of the binding directory or press F4 (Prompt) to select from a
list.
5. Press ENTER to create the new binding directory entry.
The Add Binding Directory Entry panel redisplays with a message

confirming addition of the binding directory entry. Input fields are
blank and ready for addition of another binding directory entry.
6. Do one of the following:
To add another binding directory entry, go to step Step 3
To stop adding binding directory entries, press F3 (Exit)
To delete a binding directory entry

1. Display the Work with Binding Directory Entries panel as described
in To work with binding directory entries, starting on page

DO 4-21.
2. At the Work with Binding Directory Entries panel, in the Opt field by
each entry you want to delete, type 4 (Delete) and press ENTER.
The Confirm Delete of Binding Directory Entries panel displays with
a list of entries selected for deletion.
3. Press ENTER to confirm deletion.
Technical Details
The next time you create the program after identifying an option 45
binding directory reference, Aldon LM(i) performs the following actions:
Adds the binding directory to the object creation information for the
program kept in the Aldon LM(i) object database
Removes modules named in the directory or directories which are also
in the module list from the last time the object was created from the
module list. This avoids duplication. (The exceptions to this are the
entry procedure module required in each program and any service
programs used by the program. These two types of items cannot be
specified from a binding directory and are never deleted from the
object creation information.)
Create Command Defaults and Binding

Directories
If you use a create command default for an ILE program, Aldon LM(i)
uses options specified in the default to create the program. You can leave
the binding directory parameter of the command blank to assign the
binding directory with option 45 (Assign binding directories) on the
Work with Objects by Release panel or Work with Objects by Developer
panel, or you can hard code the binding directory in the create command
default. If you specify a binding directory in the create command default,
Aldon LM(i) ignores any binding directory you may have associated with
the program using option 45.
Other Setup Recommendations for ILE Objects

Conversion of binding directories to pseudo-source based objects after
loading or mapping is recommended. This allows easy modification and
creation of binding directories within Aldon LM(i).
Using Object Dependency Data

Overview
Reference Object
The term reference object in this discussion refers to the object on
which the objects to be acted on depend. Elsewhere in Aldon LM(i)
documentation, the term reference object refers to an object used as a
model for assigning ownership and authorities to other objects. These two
uses of the phrase are completely unrelated.
Reference Release and Environment
Object dependencies are determined relative to one or more reference
objects and relative to the presence of those objects in a specific
environment of a specific release. The reference release and environment
together identify the location of the reference objects for the purpose of
assessing whether or not other objects are dependent on them.
Non-Resident Object
One important use of the object dependency information is as an aid in
populating an environment with copies of all the objects needed to test a
changed reference object promoted into that environment. Objects that
have not been changed but which are needed for testing a changed object
are dependent on the changed object. If copies of these objects dependent
objects are not present in the reference environment they are said to be
non-resident with respect to that reference environment.
A non-resident object does not actually exist in the indicated
environment, but its presence there is implied or required by one of the
reference objects. A real copy of each non-resident object exists in an
environment subsequent to the reference environment and can be used as
a source to create the non-resident object into the reference environment.
Example:
You display objects dependent on a file (the reference object) which you
have changed and promoted into QA (the reference environment). You
display objects dependent on this changed file.
The Environment for some of the programs that use the changed file is
displayed as (QUA). QUA indicates the information is about the object
relative to the Quality Assurance reference environment. The parentheses
indicates that the object is non-resident in that environment. That is, no
copy of the object actually exists in that environment, but a copy is found
using the object creation library list for the Quality Assurance
environment. Phantom files are also considered non-resident even though
they have been created in the environment by Aldon LM(i).
Acting upon Dependent Objects

Access and use object dependency data from any of the following general
starting points:
Starting with options 39 (Display requisite objects), 41 (Act upon
dependent objects), or 42 (Act upon dependent objects*) on several
Work with... panels for a wide variety of purposes
During a promote job initiated with option 7 (Promote) from any of
several Work with... panels by typing Y in the Do you wish to select
dependent objects for create field
During a checkout or emergency checkout by pressing F16 (Act upon
dependent objects)
From the More Functions panel with option 6 (Act upon dependent
objects)
See To display dependents of objects not defined to Aldon LM(i) on
page UG 2-45 in the Aldon LM(i) Users Guide for more
information.
Panels used to act upon dependent objects from all of these starting points
are similar and are discussed below.
Act upon Dependent Objects Panel

Use the Act upon Dependent Objects panel shown in Figure 29 on
page DO 4-28 to display a list of objects dependent on reference objects,
and act upon objects in the list.
This panel displays:
Object dependencies established by the Aldon LM(i) automatic scan
function accessed through the panel interface
Dependencies established manually by the user with object
dependency commands.
For instructions on using this panel see To act on objects dependent on a
given reference object, starting on page DO 4-28.
Fields on this panel are discussed below:
Upper Portion of the Panel
Reference release
Displays the name of the reference release containing the reference object
or objects in the format group/application/release.
Reference environment
Establishes the reference environment for the reference objects. This field
is sometimes input protected if you display dependent objects while
performing some actions.
If DVP, developer
If DVP is specified as the Reference environment, specifies the name of
the developer whose libraries constitute the reference environment.
Reference object(s)
For a list based on a single reference object, lists the reference object
using the format object-name type attribute. For a list based on several
reference objects, press F19 (Review reference objects) to review the list
of reference objects.
Lower Portion of the Panel
The lower portion of the panel displays the list with one record for each
dependent object.
Non-resident object environment

appears in parentheses
Environment (Views 1 and 4)

Indicates the environment of each object listed. Parentheses surrounding
the environment designation of an object indicate the object is
non-resident in that environment.
Crt. Dep (View 1)
The create dependent field displays the following values:
Y the object depends on a reference object at create time
(blank) the object depends on a reference object at execution time
Checkout Developer (View 1)
This field displays the following values:
name The developer name the object is currently checked out to is
displayed.
*MULT-n The object is checked out to more than one developer.
This can only happen in the event of an emergency checkout or an
additional standard checkout if multiple checkouts are permitted. The
number indicates the number of copies of the object currently in
development.
Y When the reference environment is DVP, a Y in this field
indicates the dependent object is currently checked out to a developer
environment other than the current reference environment.
-- Resident -Release Env (View 4)
For non-resident dependent objects, displays the release and environment
containing the next available copy of the object. The -- Resident -Release column indicates the release containing the model object. *SAME
indicates the model is located in the same release as the non-resident
dependent object. The -- Resident -- Env column indicates the
environment within the release containing the model object.
To act on objects dependent on a given reference object

1. Do one of the following:
At the Work with Objects by Release or Work with Objects by

Developer panels, in the Opt field by the reference object, type
option 41 or 42 and press ENTER
On the Work with Tasks panel, in the Opt field by a task, type
option 41 (all object in the task serve as reference objects)
At the Check Out Objects or Check Out Objects (Emergency)

panels, press F16 (Select dependent objects) (Objects selected for
checkout constitute the reference objects. The Select Dependent
Objects panel displays which is essentially the same as the Act
Upon Dependent Objects panel but limited to selected additional
objects for checkout.)
At the More Functions panel, type option 6 and press ENTER
The Act upon Dependent Objects panel displays:

CACTDEPOBJ
Act upon Dependent Objects
Reference release . .
Reference environment
If DVP, developer .
Reference object . . .
Position to . . . . .
.
.
.
.
.
:
.
.
:
.
ALDON/ACMSDEMO/BASE
PDN
DVP, ITG, QUA, PDN
+ Name
ACTGLL
*FILE
PF

2=Edit
3=Check out*
4=Delete
14=Create*
Opt Object
COMMPRT
RCVPRT
Type
*PGM
*PGM
Attribute
CBL
RPG
(*=Combined job)
7=Promote*
30=Displsy log ...
Crt Checkout
Environment Dep Developer
PDN
Y
PDN
Y
5=Browse source
17=Request promote*
D
Release
AC/BAS
AC/BAS
Subset: PriEnvObj:*CTL RefObj:Y

Command ===>
F3=Exit
F4=Prompt
F5=Refresh
F12=Cancel
F19=Review reference objects
F10=View 4
F23=More options
F11=View 2
F24=More keys
Figure 29 - Act upon Dependent Objects

Note
The same panel with some different options displays when selecting
dependent objects for creation during a promote job.
2. In the Reference environment field, type a three character
environment abbreviation for the desired environment.

3. If, for Reference environment, you typed DVP, in the If DVP,
developer field, type the name of the developer whose libraries

constitute the reference environment.
4. If you changed the Reference environment or If DVP, developer
field, press ENTER to redisplay the dependent object information

relative to the new reference environment.
5. In the Opt field by the dependent object you want to act on, type the
option number of the action you want to perform and press ENTER.
You cannot create non-resident objects into the Development
environment. You must instead perform a checkout to place them
there.
Notes
Press F5 (Refresh) after performing actions that move objects to

update information displayed on the panel.
To subset the Act upon Dependent Objects panel

Display the Act upon Dependent Objects panel as described in To act on
objects dependent on a given reference object on page DO 4-28
Prerequisite
1. Press F17(Subset) to change dependent object list subsetting using
the Subset Dependent Objects List panel shown in Figure 30 on

page DO 4-29.
CSBSDEPOBJ
Subset Dependent Objects List
Reference release . . . . . . . . :
Reference environment . . . . . . :
ALDON/ACMSDEMO/BASE
PDN
More:
Reference release:
Status in reference environment
1
Prior environments . . . . . . .
*CTL
Reference objects, if dependent
1
Other releases:
Descendent release . . . . . . .
*ALL
Sharing: Release . . . . . . . :
*NONE
Group
. . . . . . :
1
Prior environments . . . . . . .
*CTL
1
Dependent object type . . . . . .
*ALL
Recursive dependencies . . . . . . Y
Create-dependent only . . . . . . N
F3=Exit
F4=Prompt
F5=Refresh

*ALL, *CTL, D/I/Q, *NONE
1=Yes, 2=No, 3=Only
+ *ALL, generic*, name, *NONE

*ALL, *CTL, D/I/Q, *NONE
1=Yes, 2=No, 3=Only
*ALL, type
Y=Yes, N=No
Y=Yes, N=No
F12=Cancel
F22=More functions
Figure 30 - Subset Dependent Objects List Panel page 1 of 2

2. Complete the panel by working with the fields discussed below, then
press ENTER to display dependent objects meeting all subset criteria.

Specify the kinds of dependent objects to include. Select one of the
following:
1 include both resident and non-resident objects
2 include only resident objects
3 include only non-resident objects
Prior environments
Specify the prior environments from which to include dependent objects.
Prior environments are those environments closer to Development relative
to the reference environment specified above. The following values are
available:
*CTL include the controlled environments Integration and Quality
Assurance if they are prior to the reference environment. (Development is
not a controlled environment. Production is a controlled environment, but
would also require including Production environments of ancestor
releases which is not supported in the current release).
*ALL include dependent objects from all prior environments.
D/I/Q type one or more single character environment abbreviations
to include selected prior environments.
*NONE include dependent objects only from the reference
environment.
Specify whether or not to exclude the reference objects on which the list
is based from the list. Objects selected with option 41 or 42 on the
previous panel may be dependent on one another. The following values
are available:
1 (Yes) include reference objects in the list if also dependent
2 (No) exclude reference objects from the list of dependent objects
3 (Only) display only reference objects which are also dependent
Descendent release
If the reference release has descendents, specify the descendent releases
from which you wish to list dependent objects. If the reference release has
no descendents, Aldon LM(i) ignores this field.
Sharing: Release, Application, and Group
If the reference release is of a shared application, use the Release,
Application, and Group fields to select releases of sharing applications
from which to include dependent objects.
Dependent object type
Accept the default value, *ALL, to include dependent objects regardless
of type. Type an object type to include only dependent objects of that type
in the list. Press F4 (Prompt) to select from a list of types.
Recursive dependencies
Type Y (Yes) to include objects that are dependent on selected objects and
those that are dependent on the dependents of selected objects. Type N
(No) to include only objects that are directly dependent on the selected
objects.
Create-dependent only
Select dependent objects by dependency type. Type Y to included only
objects dependent on the reference objects at create time. Type N to
include objects dependent on the reference objects at create or execution
time.
To see the impact of promotion to parent on dependents

panel.
object that would be replaced by the promotion to parent you want to

simulate, type 41 (Act upon dependent objects) and press ENTER to
display the Act upon Dependent Objects panel.
For example, if you want to simulate promote to parent of an object
from a delta release to its parent, type 41 by the record for the parent
copy of the object.
3. At the Act upon Dependent Objects panel, press F17 (Subset).
The Subset Dependent Objects List panel displays.

4. Press PAGE DOWN (ROLL UP) to display the second page of the Subset
Dependent Objects List panel:

CSBSDEPOBJ
Subset Dependent Objects List
Reference release . . . . . . . . :
Reference environment . . . . . . :
ANNETTEW/SAVIO/BASE
PDN

More: As if reference objects were
promoted from release . . . .
F3=Exit
F4=Prompt
F5=Refresh
*NONE
+ *NONE, *SAME, *CHILD, name
F12=Cancel
F22=More functions
5. At the second page of the Subset Dependent Objects List panel, in the
As if reference objects were promoted from release field, type the

name of the child release from which the object would be promoted to
parent or press F4 (Prompt) to select from a list.
6. Press ENTER to display objects which would be dependent on the
reference object if it were promoted to the parent release on the Act

upon Dependent Objects panel.
Using the Development Log

To Activate or Deactivate Development Log Use for an
Application
See To Activate or Deactivate Development Log Use for an Application
on page 12-4.
To View Object Histories

To view the activity for multiple objects within an Aldon LM(i) release or
application select option 7 (Display Log) from the Aldon LM(i) main
menu.
To view the activity for multiple objects associated with an Aldon LM(i)
task, select option 5 (Work with tasks) from the Aldon LM(i) main menu.
Type option 30 (Display log) next to the task you are interested in and
press ENTER.
To view the activity for a single object, type option 30 (Display log) next
to the required object on one of the following panels:
Work with objects by release
Work with objects by developer
Act upon dependent objects
Work with requests and non-conflict conditions
The selected entries are sorted by date and time. Each log entry can be
associated with multiple tasks. This happens when an object is active for
multiple tasks simultaneously. To display detail regarding the tasks
associated with the object, see To view additional information for a log
record on page DO 4-34.
To subset to limit entries displayed, see Use Subsetting to Limit Entries

Displayed on page DO 4-33.
CDSPDEVLOG
Position to
Display Development Log

. . . . . . .
________
*TOP, *BOT, date

5=Display detail
More: Act
Er
Opt Object
Type
Release
Date
Time
Cde User
Version Cd
DEMOCBL3
*PGM
ACM/BAS 8/11/93 21:24:13 PRM MARKE
00200001 47
CLNADRL
*FILE
ACM/BAS 8/11/93 21:41:45 RMC MARKE
00100002
CLNADRL
*FILE
ACM/BAS 8/11/93 21:41:48 RMC MARKE
00100001
CLNADRL
*FILE
ACM/BAS 8/11/93 21:43:01 CAN MARKE
00100003
CLNADRL
*FILE
00200000
CLNADRL
*FILE
00100002
DEMOCBL2
*PGM
00100001
DEMOCBL3
*PGM
ACM/BAS 8/11/93 21:45:51 RMR MARKE
CLNADRL
*FILE
00300000
DEMOCBL1
*PGM
00200000
DEMOCBL1
*PGM
00100002
Subset: Rel:ALDON/ACMSDEMO/BASE (*BOT displayed: New display shows late ..
Command ===>
F3=Exit
F4=Prompt
F5=Refresh
F9=Retrieve
F10=View 5
F11=View 2
F12=Cancel
F13=Delete
F17=Subset
F21=Print
F22=More functions
Figure 31 - Display Development Log Panel, View 1 of 5
Some Actions Produce Multiple

Log Entries
The promote to parent function generates log records for both the From
child release and the To parent release.
Creates in Development Do Not

Produce Log Entries
Aldon LM(i) logs all development activities with the following single
exception: Aldon LM(i) does not log any information, including
comments, regarding creates in the Development environment. Creates in
all other Aldon LM(i) environments are logged.
Use Subsetting to Limit Entries Displayed

From the Display Development Log panel, press F17 (Subset) to display
the Subset Development Log panel. Use this panel to limit the displayed
entries by object name or type, the user who performed the operation that
generated the log entry, task, release, application, related releases, or date.
The defaults for the Subset Development Log panel are determined by the
path used to access the panel. If the Subset Development Log panel is
accessed through a specific object, using option 30 (Display log) on one
of the Work with panels, the defaults are as follows.
Release, Application, and Group are set to the values of that object.
If there is a child release associated with the objects release, and if the
child release allows promote to parent, the Related Release defaults
to *PRMFRMCHD. In all other cases, the default is *ANCESTOR.
Note
The *PRMFRMCHD subset includes activity in the child release. The

*ANCESTOR subset includes activity in ancestor releases.
If the Subset Development Log panel is accessed from the main menu,
option 7 (Display log):
Release, Application, and Group default to *USRDFT
Related Release defaults to *NONE. No activity from ancestor or
child releases is shown with this subset.
Selecting Log Entries for Display by Related Releases
On the Subset Development Log panel (F17=Subset), use the Related
releases field to limit the records displayed to those in a selected release,
and ancestors or children of that release.
Printing Development Log Reports
Print the log entries currently selected at any time by pressing F21. See
the on-line help text and Custom Reports, starting on page DO 6-2 for
details on customizing the report to meet your needs.
To view additional information for a log record

At the Aldon LM(i) main menu, type option 7 (Display log) and press
ENTER to display the Display Development Log panel.
Prerequisite
At the Display Development Log panel, do one of the following:
Press the F10 or F11 key to cycle through the four available views
on the Display Development Log panel
or
In the Opt field by a record, type 5 (Display details) and press

ENTER to display the Development Log Entry Detail panel:
CDSPLOGDTL
Development Log Entry Detail
Object . . . . .
Environment . .
Release . . . .
Activity . . . .
Date . . . . . .
Time . . . . . .
Comment . . . .
From environment
Task
NBR01
NBR02
NBR03
NBR04
NBR05
NBR06
Command ===>
F3=Exit
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
Type
BUG
ENH
F4=Prompt
ILEPGM
PDN
DOUGS/DMS52/DMS52
CRT Object created
03/19/99
09:06:02
Version . . . . . . :
Error code . . . . . :
User . . . . . . . . :
DOUGS
PDN
*SAME
Text
ASLKJF
DDDD
*PGM
00200000
More:
F9=Retrieve
F12=Cancel
Development Log Action Codes

Table 1 - Development Log Action Codes
Code
Text
ACT
Object activated via activate release function
ADD
Object added to release
BKL
Object installed live has been backed out
BKO
Object deployed has been backed out
CAN
Check out or add of object cancelled
CHG
Object description changed
CHK
Object checked out
CLC
Object cleared of conflicts
CRN
Object created as a non-resident object
CRT
Object created (note: creates in Development are not logged)
CRR
Object created for retired object
DEF
Library groups defined for the object for a release in which it is

non-resident
DLA
Object deleted from the archive library
DLE
Object deleted from environment
DLT
Object deleted from the release
ECK
Object checked out with emergency checkout
EXL
Object extracted for install live
EXT
Object extracted for deployment
INL
Object installed for install live
INS
Object installed for deployment
LOD
Object loaded to release
MGC
Object merged to parent (child record)
MGP
Object merged to parent (parent record)
MOV
Object moved to new library group, file, or member
MRG
Source code merged from multiple object versions
MRL
Object merged from selected release to target release(s)
PRC
Object promoted to parent (child record)
PLV
Object promoted with leave resident option
PRM
Object promoted
PRP
Object promoted to parent (parent record)
RAS
Checked out object transferred to different developer
Table 1 - Development Log Action Codes (Continued)

Code
Text
RET
Object retired
RMA
Acknowledgement condition for object removed
RMC
Cleared conflict condition for object removed
RMF
Failed condition has been removed
RMH
Hold condition has been removed
RMR
Request condition for object removed
RPP
Request to promote to parent
RQC
Request to checkout
RQI
Request to install live
RQP
Request to promote
RST
Object restored from archive to development
Development Log Error Codes

Error codes are two digits long. The first digit of each error code describes
the severity of the error and the second digit describes the cause of the
error. Table 2 lists the possible values.
Table 2 - Development Log Error Codes
First Digit
Second Digit
Warning
Function failed - No detail available
Completed with errors
Object not found
Failed action
Source not found
Action not attempted
Library or developer not found
Access problem
Delete of old object failed
Archive of old object failed
Failed due to cancellation of job
Object time stamp earlier than source
Object Version Numbers

For basic information on object version numbers, see Object Version
Numbers starting on page UG 3-3 in the Aldon LM(i) Users Guide.
The eight digits of an object version number are divided into two
functional parts: the first three digits are the development number and
the last five digits are the creation number. Some rules regarding the
incrementing of both parts of object version number:
Function
No
Change
Increment
DVP No.
Increment
Create No.
Add Object
Map or Load release, first time

existence for the object
Map or Load release, copies of

object exist in the application
Activate a release
Compile in Development
Promote out of Development

(with compile or
CRTDUPOBJ)
Promote from ITG or QUA
with compile
Promote from ITG or QUA
without compile
X
X
CRTNONRES with compile

CRTNONRES without compile
Compile in place in a controlled environment
X
X
X
The Aldon LM(i) copy release function maintains the version number of
the object it was copied from. The Aldon LM(i) merge to parent option
retains the version number of the merge-from (child) object in the new
object. Promote to parent is treated as promotes within controlled
environments.
Object version numbers use a 30-base number system. The numbers 0-9
are used first, then the letters B-Z, excluding all vowels and the letter Y.
The farthest right value of the DVP# side or CREATE# side will be
incremented through all numbers and letters before the next position is
incremented. Therefore, when a position reaches Z, the next number to
the left of it will be incremented.
Deleting Development Log Entries

Delete development log entries from time to time if you wish. Deleting
log entries saves disk space and speeds searches.
To delete development log entries

You must have Work with release definition authority to a release in
order to delete development log entries for that release.
Prerequisite
1. Sign on to Aldon LM(i) as a user with Work with release definition
authority for the release or releases for which you wish to delete
development log entries.
2. At the Aldon LM(i) main menu, type option 7 (Display log) and press
ENTER
to display the Display Development Log panel.
3. At the Display Development Log panel, press F13 (Delete) to display the
Delete Development Log Entries panel:

CDLTDEVLOG
Delete Development Log Entries

Release . . . . . . . .
Application . . . . .
Group . . . . . . .
BASE
+
ALDONDEMO +
Name
ALDON
+ Name
From earliest entry

through date . . . .
*CURRENT
*CURRENT, date
Run option . . . . . . .
2=Run in batch
Command ===>
F3=Exit
F4=Prompt
F5=Refresh
F12=Cancel
F22=More functions
Figure 32 - Delete Development Log Entries panel

4. At the Delete Development Log Entries panel, complete the panel and
press ENTER to delete development log entries. Delete log entries

online or as a batch job. Press Help or F1 to consult the on-line help
text for assistance.

Daily Operations
DO
Chapter 5
Working with Conditions and
Conflicts
This chapter introduces Aldon Lifecycle Manager (System i Edition) (Aldon
LM(i)) conflicts, requests, and non-conflict conditions. It explains conflict
types, condition codes, and describes the process for working with these
conditions. The following topics are included:
What are Conflicts and Non-Conflict Conditions?, starting on page
DO 5-2
Working with Requests and Non-Conflict Conditions, starting on page
DO 5-3
Working with Conflicts, starting on page DO 5-7
Setting Your Default Compare and Merge Method, starting on page
DO 5-12
Merging With Harmonizer, starting on page DO 5-13
Comparing With Harmonizer, starting on page DO 5-17
Working with the System i PCO Session, starting on page DO 5-19
Working with Conditions and Conflicts DO 5-1
What are Conflicts and Non-Conflict Conditions?

Conditions Defined
A condition is a flag in the Aldon LM(i) object database on a particular
instance of an object. Conditions provide information, and in some cases
restrict actions on the object until the condition is removed.
There are four condition types: request, acknowledgement, failure, and
hold. For more information, see Types of Requests and Non-Conflict
Conditions on page DO 5-5.
A request condition is created when a user requests checkout,
promotion, or install live of an object.
An acknowledgement condition is created to notify development
managers that normal procedures have been bypassed for a particular
object. Aldon LM(i) creates an acknowledgement condition when you
promote an object back to production after it was checked out using
the emergency checkout function. ANALYZER acknowledgement
reports achievement of the specified degrees of test coverage. The
acknowledgement condition does not restrict object movement.
A failure condition is created when a data set update has failed.
Promotion is restricted until the condition has been removed.
A hold condition is created when the physical file in the parent is
checked out to the child release. Promotion to the production
environment of the child release is restricted until the condition has
been removed. This condition is designed to make the user aware that
unless they take some action, the PF in the production environment of
the child release will not be populated with data.
The ANALYZER hold condition is created during the promotion to an
ITG or QUA environment where minimum testing requirements have
been set. The condition is automatically deleted when the specified
percentage of code has been exercised. Promotion is restricted until
the condition has been removed.
Conflicts Defined
A conflict is used to notify that a change to one instance of an object may
need to be applied to one or more other instances of the object that could
be based on the version being changed.
Conflicts are created when the notifying instance of an object is changed.
Notifying instances are defined by the relationship of releases within an
application. For example, ancestor releases always notify descendent
releases. Sibling releases can be manually defined as notifiers.
DO 5-2 Working with Conditions and Conflicts
There are always two object instances involved in any conflict:

Changed object this is the object instance in the notifying release
whose change has caused the conflict.
Conflict object this is the object instance in the notified release that
was based on the changed object before the change was made.
Promotion of conflict objects may be restricted until the conflict has
been cleared.
For information about conflict types, see Common Types of Conflicts
on page DO 5-9.
Common Causes of Conflicts
An object already in development is checked out again to another
development environment
An emergency checkout is performed and an instance of the object
resides in a development, ITG or QUA environment in the release
An object that is active (in development, integration, or quality
assurance) in an ancestor release is checked out in a descendant release
An object present in a notified release is checked out, loaded, or
copied into a notifying release. A notifying release is a release that
notifies another release of the same application of changes in objects
common to both releases. When there is a change in the production
copy of an object in the notifying release that is also present in any
environment of the notified release, Aldon LM(i) creates a release
conflict on all copies of the object in the notified release.
An object is promoted to a parent release from a child release while
the object is active in the parent release
Working with Requests and Non-Conflict Conditions

Request conditions indicate that a user wants to check out an object,
perform an install live of an object, or promote an object. Aldon LM(i)
can be set up so that specific users cannot perform these operations
themselves, but must request these operations, and then wait until
someone with authority fulfills the request. Request conditions are
displayed on the Work with Requests and Non-Conflict Conditions panel.
Requests can be completed by applying the appropriate option to
condition records on the Work with Requests and Non-Conflict
Conditions panel or to object records displayed on the Work with Objects
by Release or Work with Objects by Developer panel.
To display the Work with Requests and Non-Conflict

Conditions panel
press ENTER to display the Conditions menu.

2. At the Conditions menu, type option 2 (Work with requests and
non-conflict conditions) and press ENTER. This method displays all

conditions that meet your current subsetting specifications.
-or3. At the Work with Objects by Release or Work with Objects by
Developer panel, by an object with a condition, type 28 (Work with

conditions...) and press ENTER. This method displays requests and
non-conflict conditions only for the selected object.
This panel displays a list of the active conditions and allows you to select
specific conditions to work with. Press F17 (Subset) to display the Subset
Requests and Non-Conflict Conditions List panel. Use the subset panel to
limit the entries displayed.
CWRKCND
Position to
Work with Requests and Non-Conflict Conditions

. . . . . . .
__________

3=Check out*
4=Remove
7=Promote*
30=Display log
47=Install live*
Opt Object
AAAAAAA
ACTGLL
ACTGLP
ACTGLP2
AFFMAS
AFFMAS
AFFTRN
AFFTRN
ALTERTBL
Type
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
*TABLE
D Release
GM5/BAS
D50/D50
K D50/BD3
K D50/D50
K GM5/BAS
K GM5/DEL
K GM5/BAS
K GM5/DEL
K D50/D50

(*=Combined job)
27=Promote to parent*
Environment
DVP ADA
PDN
DVP DOUGS
ITG
DVP DOUGS
DVP DOUGS
DVP DOUGS
DVP DOUGS
DVP DOUGS
Cnd
R C
A E
R C
R P
R C
R C
R C
R C
R C
Date
02/07/07
02/14/07
01/18/07
01/18/07
01/18/07
01/18/07
01/18/07
01/18/07
01/18/07
More:
+
Initiating
User
ALISONM
DOUGS
DOUGS
DOUGS
DOUGS
DOUGS
DOUGS
DOUGS
DOUGS
Command ===> _________________________________________________________________
F3=Exit
F4=Prompt
F5=Refresh
F10=View 4
F11=View 2
F12=Cancel
F17=Subset
F24=More keys
Figure 33 - Work with Requests and Non-Conflict Conditions panel
Each condition record lists the name, type, release, and environment of
the associated object. The record also includes the name of the user whose
action created the condition, a two character condition abbreviation, and
the date that the condition was created. Checkout requests list the name of
the developer designated to receive the object in the environment column.
Press F11 to view the comment associated with each request or condition.
Cnd Column Codes: Requests, Acknowledgements, Failure, and Hold

The first character of the Condition code in the Cnd column categorizes
the condition by condition type. For example, for request conditions the
first character is R, acknowledgement is A, failure conditions is F,
and hold is H. Sections below discuss working with conditions within
each category.
Views 2, 3, and 4 provide additional information about when conditions
were created, the users involved, and the reference release and
environment involved.
Note for Delta Releases
If you are working with a delta release, on the Work with Objects by
Release panel, and the delta release does not contain a copy of an object,
conditions for the parent copy of the object are displayed. If you type 28
(Work with conditions...) by a non resident delta object, conditions on the
parent copy are not displayed.
To cancel requests or clear conditions

To cancel requests or clear acknowledgement conditions, use option 4
(Remove).
Types of Requests and Non-Conflict Conditions

Request for Checkout (R C)
A checkout request for the object has been made, but the actual checkout
has not yet occurred. Use option 3 to fulfill checkout requests. See
Checking Out Objects on page DO 3-2 for discussions of completing
checkouts.
Request for Install Live (R L)
A request for install live of the object has been made, but the actual
deployment has not yet occurred. Use option 47 to fulfill install live
requests. See Installing Live on page DO 3-29 for discussions of
completing install lives.
Request for Promotion (R P)
A promotion request for the object has been made, but the actual
promotion has not yet occurred. Use option 7 to fulfill promotion
requests. See Promoting Objects on page DO 3-10 for discussions of
completing promotes.
Request for Promotion to Parent Release (R R)

A request has been made to promote the object to the parent release of the
release in which it currently resides, but the actual promotion has not yet
occurred. Use option 27 to fulfill promote to parent requests. See
Moving Objects to a Parent Release on page DO 3-19 for discussions
of completing promotes to a parent release.
Emergency Acknowledgement (A E)
An emergency checkout/promotion acknowledgment warns supervisory
personnel that the normal development and testing cycle has been
bypassed by promotion directly to production of an object checked out
with the emergency checkout function. The acknowledgement condition
does not restrict object movement.
Data Set Update Failure (F T)
A data set associated with the environment the file was promoted into or
created in was not updated successfully. This condition warns that
programs may fail with file level checks. Promotion is restricted until the
condition has been removed.
Failure to update one or more data sets with Monitor for update errors
set to Y (Yes) with a promoted file creates a fail test data update
condition (F T) to warn that testing of the file may not be complete. Use
the following steps to clear this condition:
To remove a data set update failure condition

1. Correct the problem that prevented the data library update.
2. Re-create the file in-place in the desired environment using option 14
(Create), on the Work with Objects by Developer or Work with

Release Objects panel. This automatically updates the data set with
the new format of the file.
3. Provided the update ran successfully, remove the condition with
option 4 on the Work with Requests and Non-Conflict Conditions

panel.
ANALYZER Cleared (A A)
The copy of the program object associated with this conflict met testing
requirements that were specified in Aldon LM(i). The test coverage is
measured by ANALYZER when you run the ANALYZER Display
Report.
ANALYZER Hold (H A)
You set testing requirements for this copy of the program object on
promotion into the current environment. During promotion, ANALYZER
temporarily instrumented the program for collection of testing statistics.
Aldon LM(i) changes this condition to an A A ANALYZER
acknowledgement condition when ANALYZER reports achievement of
the specified degrees of test coverage. ANALYZER evaluates test
coverage when you run the ANALYZER Display Report. Promotion is
restricted until the condition has been removed.
For more information about ANALYZER, see Establishing and Meeting
Testing Standards with ANALYZER starting on page UG 2-54 in the
Aldon LM(i) Users Guide.
Delta Release Data Hold (H D)
The physical file associated with this condition was checked out to a Delta
release from another release. This condition prevents promotion of the file
into the production environment of the delta but not into Integration or
Quality Assurance. The condition reminds users that manual loading of
data into the file from other releases may be required.
Working with Conflicts

A conflict may limit the promotion of an object. Resolve the differences
between the conflicting objects, clear the conflict, then promote the
object.
The Work with Conflicts panel displays a list of conflicts with the status,
conflict type, and the changed object. You can select the specific
conflict(s) to work with.
To display the Work with Conflicts panel

press ENTER to display the Conditions menu.

2. At the Conditions menu, type option 1 (Work with conflicts) and
press ENTER. This method displays all conflicts that meet your current
subsetting specifications.
-or3. At the Work with Objects by Release or Work with Objects by
Developer panel, by an object with a condition, type 12 (Work with

conflicts...) and press ENTER. This method displays conflicts only for
the selected object.
This panel displays a list of the conflicts and allows you to select specific
conflicts to work with. Press F17 (Subset) to display the Subset Conflicts
List panel. Use the Subset panel to limit the entries displayed.
CWRKCNF
Position to
Work with Conflicts

. . . . . . .

2=Clear*
5=Display detail
Opt Object
ACMSLIB
ACTGLL
ACTGLL
ACTGLL
ACTGLL
ACTGLL
ACTGLL
ACTGLL
ACTGLP
ACTGLP
ACTGLP2
Type
*SRCMBR
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
*FILE
19=Merge
D Release
DHS/DB1
D50/DS2
D50/DS2
D50/DS3
D50/DS3
D50/DS3
D50/BD3
D50/BD3
K D50/DS2
K D50/BD3
K D50/DS2
30=Display log
Environment
DVP DMITRIS
PDN
PDN
PDN
PDN
PDN
PDN
PDN
PDN
PDN
PDN
Sts
ACT
AP
ACT
AP
ACT
ACT
AP
ACT
INA
INA
AP
Typ
MCK
RCK
RCK
RCK
RCK
RCK
RCK
RCK
RCK
RCK
RCK
(*=Combined job)
35=Compare
More:
+
- Changed Object Rel Environment
*
QUA
D50 ITG
D50 PDN
D50 ITG
D50 PDN
DS2 PDN
D50 ITG
D50 PDN
D50 DVP DOUGS
D50 DVP DOUGS
D50 ITG
Command ===> _________________________________________________________________
F3=Exit
F4=Prompt
F5=Refresh
F10=View 4
F11=View 2
F12=Cancel
F17=Subset
F24=More keys
Figure 34 - Work with Conflicts Panel
Each conflict record lists the name, type, release, and environment of the
associated object. The record also includes the conflict status, a three
character conflict type abbreviation, and the release and environment of
the changed object. Press F11 to view the comment associated with each
conflict.
View 2 indicates if there is a reference source available for merge.
Conflict Status
A conflict can have one of the following statuses.
Active (ACT)
Restrictions on promoting the conflict object are defined at the release
level.
Active pending (AP)
Applies to release conflicts where the changed object is in either ITG or
QUA of the notifying release. It indicates that the changes may not yet be
finalized so it may be too early to resolve the conflict object. Restrictions
on promote are the same as for an active conflict.
Clear pending (CP)

Any active conflict that will be cleared by the promotion of a cleared
conflict. Restrictions on promote are the same as for an active conflict.
Cleared (CLR)
A conflict that has been marked as cleared. For instance, the conflicting
object now contains the changes made to the changed object. There are no
restrictions on promoting the object.
Inactive (INA)
Any conflict for which the changed object is in a development
environment. The conflict object can normally be promoted. The
exception being an emergency check out when the conflict object would
go into the production environment that is the target of the emergency
checkout.
Common Types of Conflicts

These conflicts are based on the changed object. This is the object
instance in the notifying release whose change has caused the conflict.
Release Conflict (REL) - A conflict type of REL displays when the
changed object and conflict object reside in different releases.
Multiple Checkout Conflict (MCK) - More than one instance of the
object is checked out to development in the same release, each copy is
both a changed and a conflict object in relation to each other.
Emergency Checkout Conflict (ECK) - an emergency checkout caused
the changed object to go into the production environment ahead of the
conflict object.
Promote from Child Conflict (PFC) - the promotion of an object from a
child release to the production environment of the parent release creates a
conflict on any instance active in the parent release.
Merge Conflict (MRG) - is created when a merge to parent is done and
there is an active instance of the object in the parent release.
Release Checkout Conflict (RCK) - the changed instance of the object
was checked out in the notifying release.
Add Conflict (ADD)
Adding a new version of the object to a notifying release sets a conflict on
any instance resident in a notified release.
Delete Conflict (DLT)

Deleting the version in a notifying release sets a conflict on any instance
resident in a notified release.
Less Common Conflict Types

These conflicts are based on the changed object. This is the object
instance in the notifying release whose change has caused the conflict.
Load Conflict (LOD)
Loading a new version of an object to the production environment creates
a conflict on any active instance in the same release or resident in notified
releases.
Delete From Environment Conflict (DLE)
Deleting the object in a notifying release creates a conflict in a child
release only if there is an instance in a parent release of the deleted object.
Retiring the middle release instance rather than deleting it always
causes a RCK conflict.
Delete Changed Object of Cleared Conflict (DCC)
When a conflict is cleared, Aldon LM(i) assumes that changes were made
to the conflict object to match the changes made to the changed object.
Therefore, if the changed object is subsequently deleted, Aldon LM(i)
creates a new conflict if the following conditions are met:
The conflict was cleared in the development environment, therefore it
is assumed changes were made to the conflict object to match the
changed object.
The changed object was resident in an active environment (DVP, ITG,
or QUA) when it was deleted and that there is another instance of the
object in a higher environment within the same release.
Activate Conflict (ATV)
Indicates that the conflict was created during the activation of a new
release that was set as the notifier of another existing release.
Foreign Checkout Conflict (FRN)
Can occur if an object is added or checked out to a notifying release as a
result of the ACMSCHKFRN command.
Resolving and Clearing Conflicts

Before clearing a conflict, merge changes from the conflict copy and the
changed copy of the object to prevent overwriting of changes on
promotion.
You can merge the changes manually or use Aldon Harmonizer or Aldon
Harmonizer (Windows Edition). If you have Harmonizer installed, type a
19 to merge modified versions of source into a single source file. If
Harmonizer is not installed, this option does not appear. For more
information about using Harmonizer, seeMerging With Harmonizer,
starting on page DO 5-13.
To clear a conflict
1. Determine if any changes are required to the conflict object. If not,
the conflict can be cleared from Work with Conflicts panel by typing
2 (Clear*) by the conflict record. No further action is needed.
2. If changes are required, check the conflict object out.
3. Use Harmonizer or manually apply the required changes, compile and
test. For more information about using Harmonizer, seeMerging

With Harmonizer, starting on page DO 5-13.
4. Clear the conflict on the development copy only.
5. You can now promote the development copy of the object using
option 7 (Promote*).
Promoting Cleared Conflicts

Aldon LM(i) tracks related conflicts and auto clears conflicts where
possible.
Clearing of a conflict on one instance of an object automatically clears
related conflicts on other versions of the object when the cleared version
is promoted to the environments of the other versions.
Each conflict has its own internal tracking number. Cleared conflicts are
marked, not deleted, until all objects affected by the conflict are cleared.
Promoting Multiple Checkouts
Aldon LM(i) simplifies promotion following multiple checkouts by
enabling you to promote inactive (changed object is in development)
conflicts and specifying the environment up to which active conflicts can
be promoted.
Rules for Promoting Conflict Objects

There are no restrictions on promoting a cleared conflict object.
An inactive conflict object can be promoted, except to a production

environment that is the target of an emergency checked out object.
A non-cleared conflict object can never be promoted to the
environment of the changed object. That is, the conflict object can
never overwrite the changed object unless the conflict has been
cleared.
The environments to which an active, active pending, and clear
pending object may be promoted are governed by the release
definition. For more information, see Defining a Release starting on
page SA 14-1 in the Aldon LM(i) Setup and Administration
Reference
Setting Your Default Compare and Merge Method

When both Harmonizer (Batch) and Harmonizer (Windows) are available,
users can set their individual default for the Compare and Merge method
to be used.
To set default options for compare and merge method

1. Press F22 (More functions) from most panels within Aldon LM(i) to
display the More Functions panel.

At the More Functions panel, in the Opt field, type 3 (Set operation
defaults) and press ENTER. The Set User Operation Defaults panel
displays.:
CUSROPRDFT
Set User Operation Defaults

More: 5. Compare and merge methods
The compare and merge functions include the following option if both
Harmonizer and Harmonizer for Windows are installed on your system.
Please specify your default entry for this option, if it is available.
Compare/merge method . .
F3=Exit
F5=Refresh
1=PC, 2=Batch
F12=Cancel
Figure 35 - Set User Operation Defaults panel, page 3 of 3
2. Page Down to the third panel to 5. Compare and merge methods
field. Type 1=PC to run interactively or 2=Batch for batch execution

for the compare and merge methods. Use the Page Up or Page Down
key to move between the three panels.
Merging With Harmonizer

Resolving Conflicts Using Merge
You must have a licensed copy of Aldon's Harmonizer or Harmonizer
(Windows Edition) installed and set up to use this function. To use
Harmonizer (Windows Edition) you must also have the PC part of the
product installed on your PC and be using IBM Client Access to view the
Aldon LM(i) screens. For more information, see Setting up Harmonizer
and Harmonizer (Windows Edition) starting on page SA 5-1 in the
Aldon LM(i) Setup and Administration Reference.
To resolve a conflict using Merge

We recommend that the conflict object be checked out prior to executing
the merge and the merge should be done against the conflict on the
checked out copy.
1. At the Work with Objects by Developer or the Work with Objects by
Release panel, in the Opt field by the object flagged with the conflict
condition, type 12 (Work with conflicts) and press ENTER. The Work
with Conflicts panel, shown in Figure 25 on page UG 2-49, displays.
2. In the Opt field by the conflict record, type 19 (Merge) and press
ENTER.
Note
The Merge Source panel displays.
Merge (option 19) is not available if:
Harmonizer or Harmonizer (Windows Edition) is not installed
The object is not source based
The reference source is not available
CMRGSRC
Merge Source
Object . . . . . . . . .
Release . . . . . . . .
Environment . . . . . .
Changed object: Release
:
:
:
:
:
ACMSLIB
*SRCMBR
DMITRIS/DIMAAPP/BASE1
DVP DMITRIS
BASE1
Environment . . . :
QUA

Merge source into:
File . . . . . .
Library . . .
Merge method . . .
Comment for log .
.
.
.
.
.
.
.
.
.
.
.
.
MERGESRC
DMITRIS2
Name, *DVPSRC
Name
1=PC, 2=Batch
Command ===> _________________________________________________________________

F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F15=Full name
Figure 36 - Merge Source panel

3. At the Merge Source panel identify the file and library to receive the
merged source produced by Harmonizer.

You can use any Aldon LM(i) library you choose. Accepting the
default file name, MERGESRC prevents overlay of source
members by the same name that might be present in your developer
library.
The *DVPSRC option replaces the existing checked out source with
the output from the merge. This option is only available if the object
is already checked out and the merge method selected is PC.
4. In the Merge method field, type 1 (PC) to run the merge job
interactively. Type 2 (Batch) for batch execution. You may set your
default of PC or batch from F22 More options. If merge method
displays as 1 or 2 and is not changeable, then the product to support
the other function has not been installed or set up.
5. Press ENTER.
For batch jobs A batch job is submitted that produces a printed

report indicating additions, deletions, and changed lines being
applied to the reference source and from which of the two
sources in conflict the change originated. The merged source is
output to the requested file.
For PC The compare screen is displayed as a separate window on
your PC. The left pane displays the source for the conflict object
and the right pane displays the source of the changed object. The
bottom pane displays the results of the merged members. The
merge result may be edited before saving. For more information,
see Navigating The PC Merge Window starting on page
DO 5-15 in the Aldon LM(i) Daily Operations Reference.
6. If not already checked out, check out the object and replace the
checked out source with the merged source.

7. Compile and test the new merged source.
8. Clear the conflict condition as described in To clear a conflict
below.
9. Promote the copy containing the integrated changes from
Development.
Navigating The PC Merge Window

The top panes show the differences between the two objects in conflict
and the reference object. The bottom pane shows merged source.
Conflicting records are highlighted in yellow and occur where the same
record was changed in both the sources being merged. Deleted lines are
shown with a strike through. You can use F5 and F6 to jump between
conflicts and use Ctrl A to accept conflicts or edit the merged source
before saving.
The letters beside the sequence number and change date in the top panes
represent:
R Matches reference source
I Inserted
D Deleted
The letters beside the sequence number and change date in the bottom
pane represent:
R Matches reference source in both sources
A Changed in source shown in top left pane
B Changed in source shown in top right pane
The merge result is editable so conflicting records can be instantly
resolved.
When you have completed the merge activities, clicking Save displays the
save confirmation window indicating where the merged source is to be
saved. If this dialog is closed without saving the merged member, a
message box displays informing you that the merge result will not be
saved and do you want to continue. Select Y (Yes) for the merge window
to close with no save. Select N (No) to return to the merge window.
Once the save is complete, the PC program runs the System i clean up
command and then closes.
Figure 37 - PC Merge Window
Batch Merge Report

The printed batch report identifies additions, deletions, and changed lines
being applied to the reference object and from which of the two objects in
conflict the change originated. For more information, see Harmonizer
Users Guide.
Figure 38 - Batch Merge Report
Comparing With Harmonizer

Selecting Objects to Compare
Use Compare (option 35) to select the two instances of a source based
object to compare. The member selected on the Compare panel becomes
the comparefile copy. The newer version of a program is usually
selected as the comparefile copy.
To select copies of the object to compare

1. At the Work with Objects by Developer, Work with Objects by
Release, or the Work with Conflicts panel, in the Opt field by the
object, type 35 (Compare).
2. Press ENTER. The Select Copies of Object for Compare Source panel
displays.
Note
If Harmonizer or Harmonizer (Windows Edition) is not installed, option

35 is not available.
CSELSCP
Select Copies of Object for Compare Source
Object name . . :
Application . . :
ARS277
CATHY/CATHY
Object type . . . :
Selected release . :
*PGM
CATHYC
Type choice.
Compare method . . . . .
1=Select as compare file
Opt
2
1
Environment
QUA
PDN
DVP CATHYC
DVP CATHY3
PDN
PDN
1=PC, 2=Batch
2=Select as reference file
Release
CATHYC
CATHYC
DELTA1
DELTA1
DELTA1
CATHYB
Lvl
BASE
BASE
1
1
1
BASE
Command ===> _________________________________________________________________

F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F15=Full name
Figure 39 - Select Copies of Object for Compare Source Panel

3. In the Compare method field, type 1 (PC) to run the compare job
interactively. Type 2 (Batch) for batch execution. You may set your
default of PC or batch from F22 More options.
4. If the compare option was taken from the Work with Conflicts
display, the changed object defaults to be the compare source

(1=Select as compare file) and the conflict object defaults to be the
reference source (2=Select as reference file). When coming from the
Work with Objects by Release or Developer panel, the selected

instance defaults to the compare file (1) and the reference file (2)
must be selected.
5. Press ENTER.
Note
For batch jobs A batch job is submitted that produces a printed

report indicating additions, deletions, and changed lines made to
the compare version.
For PC The compare screen is displayed as a separate window on
your PC. The left pane displays the compare file and the right
pane displays the reference file. Differences are highlighted by
lines connecting the two panes. For more information, see
Navigating The PC Merge Window starting on page DO 5-15
in the Aldon LM(i) Daily Operations Reference.
Navigating The PC Compare Window

Harmonizer (Windows Edition) indicates the additions, deletions, and
changed lines in the compare window. The differences are colorfully
identified with highlighted blocks pointing to the differences.
You can select Sync Panes from the View drop-down list box, to enable
your window panes to scroll in sync. Use F7 and F8 to skip to the next
difference.
When you have completed the compare, close the window. All ways of
closing the window work the same. The PC program runs a command on
the System i to clean up the work files.
Figure 40 - PC Compare Window
Batch Compare Report

The printed report identifies additions, deletions, and changed lines.
Figure 41 - Batch Compare Report
Working with the System i PCO Session

Harmonizer (Windows Edition) is only available from within Aldon
LM(i).
After you have selected the compare or merge options, press ENTER. The
System i PCO Session N command Prompt window displays and remains
blank.
Figure 42 - PCO session A command prompt
The compare or merge panel then displays as a separate window. The

PCO session N command prompt window must remain open during the
compare or merge session. Closing it causes the compare or merge panel
to terminate without saving the merge output or cleaning up the work files
in System i. Returning focus to the Aldon LM(i) session allows you to
continue working on that panel without affecting the compare or merge
displayed. Further compares and merges may be selected, with a new
window being opened for each one.
Note
Be aware that if you select multiple simultaneous merges to the same

target source as you close each merge the source will be overwritten with
the output from that merge.

Daily Operations
DO
Chapter 6
Reports
Overview of Reports
Many Aldon Lifecycle Manager for System i (Aldon LM(i)) panels include a
print function which, when used with subsetting criteria, provides a wide
variety of custom reports. Aldon LM(i) also provides fixed format reports to
display the results of operations, Aldon LM(i) setup values, and information
about applications, releases, objects, and tasks. This chapter describes and
provides an example of the custom report printing capability and provides
samples and descriptions of the most important fixed format reports.
Page Headings
Headings print at the top of all report pages. On the first header line, the
product and version appear at the left, the name of the report is centered, and
the page number appears at the right. On the second line, the name of the
printer file appears at the left, copyright information is in the center, and the
date and time the report was generated appear at the right.
The first page of all reports also lists the Job number, profile, and device or
program from which the report was requested at the left on line three, and the
CPU serial number (or Demo at) and company name in the center of line
four. The company name is specified during the installation procedure and
may be changed by re-running the Install program.
Reports DO 6-1
Custom Reports
Create custom reports from many Aldon LM(i) panels using F21=Print.
Control custom reports by controlling the list of items, the range of items
printed, and the fields printed for each item.
Control the list
Control the list of items available for inclusion in the report by subsetting
the Work with panel with F17=Subset and/or F22=More functions
before requesting the report. Subsetting Work with panels is discussed
in Subsetting a Work with Panel on page DO 2-15.
Control the range
Control the range printed from the available list by specifying the First
entry and Last entry to print on the confirmation panel. Accept
defaults *TOP and *BOT for First entry to print and Last entry to
print to print the entire list, or restrict the range by entering all or part of
an item name as a starting or ending point. For example if the report lists
information about objects, enter all or part of an object name to specify a
First or Last entry to print. Enter *TOPSCREEN to specify the first item
visible at the top of the list when you pressed F21. Enter *BOTSCREEN
to specify the last item visible when you pressed F21.
Control the fields
Control the fields of information printed for each item by selecting a
View with F11 on the confirmation panel. The view selected determines
which fields appear on the report. Report views are similar to but
independent from views selected on Work with panels. View selection
is not currently available for all reports.
Custom Report Example

This example demonstrates printing the custom report for the Work with
Objects by Developer panel.
Control the List
The Work with Objects by Developer panel displays active objects, and
may be subset by developer, environment, object, type, attribute,
condition, task, release, application, and application group. In this
example, the panel is subset for Developer = ACMSDEMO,
Release=BASE, Application=ACMSDEMO, and Group=ALDON.
DO 6-2 Reports
After setting the subset criteria, press F21 from the Work with Objects by
Developer panel to display a Confirm Print of List panel such as the one
shown in Figure 43.
CFMPRTDVO
Confirm Print of List
Type choices, press Enter to confirm your request to print the list.
Press F12=Cancel to cancel your print request.
First entry to print . . .
*TOP
*TOP, *TOPSCREEN,
starting characters
Last entry to print
*BOT
*BOT, *BOTSCREEN, *MATCH,

starting characters
. . .
This print view prints the following fields:

object, type, attribute, release, developer, Env, Lvl, version, conditions
F11=Print view 2
F12=Cancel
Figure 43 - Confirm Print of List Panel
Control the Range

This example uses the default values *TOP and *BOT. *TOP begins the
print range with the first record selected by current subsetting criteria.
*BOT ends the print range with the last record selected by current
subsetting criteria. *TOPSCREEN and *BOTSCREEN begin and end the
print range with the records displayed at the top and bottom of the
previous panel on entry into the print function. Enter a character string for
First or Last entry to print to begin or end the print range with the first or
last record matching the specified string. Aldon LM(i) evaluates the string
entered against the primary key field used to sort records on the previous
panel. In this example, object name is the primary key field. Enter
*MATCH for Last entry to print to print only records matching the record
specified in the First record to print field.
Reports DO 6-3
Control the View

Three Views are available for printing the Work with Objects by
Developer panel:
View
Fields Included
Object, Type, Attribute, D, Release, Developer, Env,

E, Checkout requests, conditions
Object, Type, Env, Version, Release, Lvl
Object, Type, Env, Object library, Source; Library,

File, Member
Object, Type, Text
Select the desired view with F11, then press Enter to produce the report.
Figure 45 on page DO 6-5 shows a sample View 1 report. Figure 44 on
page DO 6-4 shows a sample View 2 report. Figure 45 on page DO 6-5
shows a sample View 3 report.
..
Aldon LM(i) version V084_07.5
Printer file PRT
FDVPOBJ
Job 066734/ALISONM/QPADEV000J

Copyright (c) Aldon, Inc. 1989-2004
JULY
6, 2007
Page
1
11:04 AM Job
Licensed at Aldon Computer Group Inc.

Subsets in effect:
Developer . . . . . .
Environment . . . . .
Object . . . . . . . .
Object type . . . . .
Object attribute . . .
Has condition category
Included in task . . .
Release . . . . . . .
Application . . . .
Group . . . . . .
Range in effect:
First entry printed .
Last entry printed . .
Object
==========
CLNADR
CLNADR
CLNADRL
DEMOCBL1
DEMOCBL2
Type
========
*FILE
*FILE
*FILE
*PGM
*PGM
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
. :
. :
*ALL
*ACT
*ALL
*ALL
*ALL
*NA
*NA
BASE
ACMSDEMO
ALDON
*TOP
*BOT
Attribute D Release
==========
================================
PF
ALDON/ACMS4.0/CMS7.31
PF
LF
CBL
K ALDON/ACMS4.0/CMS7.31
CBL
* * * * *
E N D
O F
Developer
==========
ALISONM
ALISONM
ALISONM
ALISONM
ALISONM
Env
===
DVP
QUA
QUA
QUA
DVP
L I S T I N G
Lvl
====
BASE
BASE
BASE
BASE
BASE
Version
========
00100002
00100001
00100001
00100001
00100001
-- Conditions Chkout rqs Oth Emg

========== === ===
* * * * *
Figure 44 - Work with Objects by Developer Report view 1
DO 6-4 Reports

Printer file PRTFDVPOBJ

JULY
6, 2007
Page
1
11:04 AM Job

Subsets in effect:
Object . . . . . . . .
Release . . . . . . .
Application . . . .
Group . . . . . .
Range in effect:First entry printed .
Object
==========
CLNADR
CLNADR
CLNADRL
DEMOCBL1
DEMOCBL2
Type
========
*FILE
*FILE
*FILE
*PGM
*PGM
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
. :
. :
*ALL
*ACT
*ALL
*ALL
*ALL
*NA
*NA
BASE
ACMSDEMO
ALDON
*TOP
*BOT
Attribute D Release
Developer
==========
====================== =========
PF
ALDON/ACMS4.0/CMS7.31 ALISONM
PF
LF
K ALDON/ACMS4.0/CMS7.31 ALISONM
CBL
K ALDON/ACMS4.0/CMS7.31 ALISONM
CBL
* * * * *
E N D
O F
Env
===
DVP
QUA
QUA
QUA
DVP
Object
Library
==========
MARKE
ACMBASQUAL
ACMBASQUAL
ACMBASQUAL
MARKE
L I S T I N G
------------ Source ----------Library

File
Member
========== ======== ==========
MARKE
QDDSSRC
CLNADR
ACMBASQUAL QDDSSRC
CLNADR
ACMBASQUAL QDDSSRC
CLNADRL
ACMBASQUAL QCBLSRC
DEMOCBL1
MARKE
QCBLSRC
DEMOCBL2
* * * * * *


JULY
6, 2007
Page
1
11:04 AM Job

Subsets in effect:
Object . . . . . . . .
Release . . . . . . .
Application . . . .
Group . . . . . .
Range in effect:
First entry printed .
Object
==========
CLNADR
CLNADR
CLNADRL
DEMOCBL1
DEMOCBL2
Type
=======
*FILE
*FILE
*FILE
*PGM
*PGM
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
. :
. :
*ALL
*ACT
*ALL
*ALL
*ALL
*NA
*NA
BASE
ACMSDEMO
ALDON
*TOP
*BOT
Attribute D Release
==========
=====================
PF
PF
LF
CBL
CBL
* * * * *
Developer
==========
ALISONM
ALISONM
ALISONM
ALISONM
ALISONM
E N D
O F
Env
====
DVP
QUA
QUA
QUA
DVP
Text
====================================
CLNADR Physical File for Aldon/CMS Demo
CLNADR Physical File for Aldon/CMS Demo
CLNADRL Logical File for Aldon/CMS Demo
COBOL DEMO Program - Main Module
COBOL DEMO Program - 1st Subordinate Module
L I S T I N G
* * * * *
Reports DO 6-5
Checkout Report - PRTFCHKOUT

When objects are checked out to a Developer, Aldon LM(i) can produce a
report which summarizes the results of the checkout operation. This
report, which is shown in Figure 47 on page DO 6-6, lists all of the
objects checked out. It also names the release for which the checkout is
performed, the object name, type and attribute, the release and
environment containing the checkout copy, the receiving developer, and
the checkout comment. If any errors occurred during the checkout
operation, they are listed on this report. Correct the errors and repeat the
checkout operation.
To print a checkout report

1. Begin to check out objects in the normal way.
2. On the Check Out Objects panel, in the Print checkout report field,
type Y (Yes).
3. Complete the checkout in the normal way.
Checkout
JULY
6, 2007
Page
1
11:04 AM Job

---- From ----Release
Object
Type
Attribute
Release
Env Developer
Comment
================================ ========== ======== ========== ========== === ========== ===========================
ALDON/ACMSDEMO/BASE
CLNADR
*FILE
PF
*SAME
PDN ALISONM
ALDON/ACMSDEMO/BASE
DEMOCBL1
*PGM
CBL
*SAME
PDN ALISONM
ALDON/ACMSDEMO/BASE
DEMOCBL2
*PGM
CBL
*SAME
PDN ALISONM
3 objects were checked out.
Program ACMSCHKOUT completed successfully. The highest CMSnnnn message severity received was 0.
Figure 47 - Checkout Report
DO 6-6 Reports
Promote/Create Object Report - PRTFPROMOT

Aldon LM(i) can create source-based objects automatically when they are
promoted, or you can request creation in place in a developer library or in
an Aldon LM(i) controlled library.
Aldon LM(i) produces a report for each create or promote job. The report
title changes depending on the operation(s) performed. If a job combines
promote and create operations, as when creating dependent objects during
a promote job, the title reads Promote/Create Object Report.
This report, shown in Figure 48 on page DO 6-7, displays the release
name, the promote or create comment, the name, type, attribute, and the
From and To environments for each object. The second column
displays P for a promote or C for a create operation.
When objects are recompiled as a part of the promotion operation, the
report displays the create command used. The report also displays the
extended attribute of any program objects listed. An Aldon LM(i)
information message appears for each object scanned for object
dependency data. Any errors that occurred during the promotion are
listed, allowing the user to correct the errors and repeat the promotion
operation.
When a non-resident object is created, the far right columns display the
release and environment containing the model object the new copy is
created from.
Promote/Create Objects
JULY
Page
1
6, 2007 11:04 AM Job
CMS1343
Non-Res Create
Ext From
To
From
Attribute Attr Environment Env Release
Env Comment
========== ==== ============ === ========== === =========================
PF
QUA
PDN
FILE(DS1DS1PDN1/DMSPF01) SRCFILE(DS1DS1PDN1/QDDSSRC) SRCMBR(DMSPF0
FILETYPE(*DATA) MBR(DMSPF01) EXPDATE(*NONE) MAXMBRS(00001) MAINT(*I
D) RECOVER(*NO) FRCACCPTH(*NO) SIZE(0000010000 01000 00003) ALLOCAT
NO) CONTIG(*NO) UNIT(*ANY) FRCRATIO(*NONE) WAITFILE(*IMMED) WAITRCD
060) SHARE(*NO) DLTPCT(*NONE) ALWUPD(*YES) ALWDLT(*YES) LVLCHK(*YES
TEXT(' ')
Object DMSPF01 type *FILE successfully scanned in environment PDN.
CMS2347
Data library DS1DS1PDTA was successfully updated for file DMSPF01.
P
Release
C Object
Type
======================= = ========== ==========
DOUGS/DMS01/DMS01
P MSPF01
*FILE
CRTPF
CMS2350 0 Data library DS1DS1QDTA not updated for file DMSPF01 because the file was at the same level as
in env QUA.
DOUGS/DMS01/DMS01
C DMSLF01
*FILE
LE
PDN
CMS1343 0Object DMSLF01 type *FILE successfully scanned in environment PDN.
CMS2347 0Data library DS1DS1PDTA was successfully updated for file DMSLF01.
1 objects were promoted.
1 objects were created.
Program ACMSCREATE completed successfully. The highest CMSnnnn message severity received was 0.
Figure 48 - Promote Objects Report
Reports DO 6-7
Object Data Report - PRTFPRTOBJ

Select an object with option 11 on the Work with Objects by Release
panel to print a complete description of the object from the Aldon LM(i)
object tracking database. The report lists the Aldon LM(i) controlled
libraries the object passes through during the development cycle, and
tasks and deployment sets the object is a member of. A table lists the
version number, location, developer, and any conditions pending for each
copy of the object. A release abbreviation followed by *NOT RES
indicates the object is not currently resident in the indicated environment.

OBJECT DATA
JULY
6, 2007
Page 1
11:04 AM Job
Licensed at Aldon Computer Group Inc

ACMSADDREL
*PGM
GARYM/GARYMAPP/BASE
Ext Dta
Scan
Object
---------------- Source ---------------Environment
Release
Attribute
Attr Opt Version
Status
Library
Library
File
Member
Type
============== ========== ========== === === ======== ======== ========== ========== ========== ========== ======
PDN
*SAME
PF
KEP 00100000 *CURRENT ACMBASPDN1 ACMBASPDN1 QCBLSRC
DEMOCBL1
Normal
Object library group:
1 Object
Source library group:
2 Source
Tasks
. . . . . . . . :
ACMS004669
Object text . . . . . . :
Create command . . . . : CRTCBLPGM PGM(ACMBASPDN1/DEMOCBL1) SRCFILE(ACMBASPDN1/QCBLSRC) SRCMBR(DEMOCBL1)
Object . . . . . . . . :
Type . . . . . . . . . :
Release . . . . . . . :
QUA
*NOT RES
*SAME
ACMBASQUAL
ACMBASQUAS
QCBLSRC
DEMOCBL1
ITG
*SAME
CBL
OPM
00100100 *CURRENT ACMBASINTG ACMBASINTS QCBLSRC
DEMOCBL1
Object text . . . . . . :
Create command . . . . :
CRTCBLPGM PGM(ACMBASINTG/DEMOCBL1) SRCFILE(ACMBASINTS/QCBLSRC) SRCMBR(DEMOCBL1)
Normal
Checkout requests
=================
Task
==========
ACMS004669
Dply. Set
=========
0000015
0000065
Text
==================================================
Add development log rcds for install/back out
Status
======
Deployment started
New
* * * *
End of Listing
* * * *
Figure 49 - Object Data Report
DO 6-8 Reports
Development Log Report - PRTFDSPLOG

Aldon LM(i) maintains a log of all development operations it performs.
Development operations include checkouts, promotions, additions of new
objects to a release using the Map, Load, and Copy Release, add object
functions, cancellations of checkouts, deletions of objects, and creation of
object in place. If you request an operation that affects multiple objects,
Aldon LM(i) generates a separate log entry for each object. For example,
simultaneous checkout of three objects produces three log entries.
On the Display Development Log panel, press F21 to print development
log reports.
Customize the development log report by subsetting the Display
Development Log panel with F17, and by selecting the range of records
and set of fields to print on the Confirm Print of List panel..

JULY
6, 2007
Page
1
11:04 AM Job

Subsets in effect:
Object . . . . . . .
Object type . . . .
Activity code . . .
User . . . . . . . .
Affects task . . . .
Release . . . . . .
Application . . .
Group . . . . .
Related releases . .
From date . . . . .
To date . . . . . .
Range in effect:
First entry printed
Last entry printed .
Object
========
DEMOCBL1
DEMOCBL2
DEMOCBL3
DEMORPG1
DEMORPG2
DEMORPG3
CLNADRL
CLNADR
DEMOCBL1
DEMOCBL2
CLNADR
DEMOCBL1
DEMOCBL2
DEMOCBL2
Type
======
*PGM
*PGM
*PGM
*PGM
*PGM
*PGM
*FILE
*FILE
*PGM
*PGM
*FILE
*PGM
*PGM
*PGM
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
. . :
. . :
*ALL
*ALL
*ALL
*ALL
*NA
BASE
ACMSDEMO
ALDON
*NONE
*FIRST
*LAST
*TOPSCREEN
*BOTSCREEN
Release
====================
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
ALDON/ACMSDEMO/BASE
Act
Date
Time
Cde
======= ======== ===
1/16/95 18:10:40 LOD
1/16/95 18:10:50 LOD
1/16/95 18:10:58 LOD
1/16/95 18:11:06 LOD
1/16/95 18:11:18 LOD
1/16/95 18:11:28 LOD
1/16/95 18:11:51 LOD
1/17/95 9:38:15 CHK
1/17/95 9:38:22 CHK
1/17/95 9:38:24 CHK
1/17/95 10:15:26 PRM
1/17/95 10:15:53 PRM
1/17/95 10:16:02 PRM
1/17/95 11:04:10 CRT
* * * * *
E N D
Er
Cd
==
Version
=======
00100000
00100000
00100000
00100000
00100000
00100000
00100000
00100001
00100001
00100001
00100001
00100001
00100001
37 00100001
O F
L I S
--------- From ---------Release

Environment
========== ==============
*SAME
*SAME
*SAME
*SAME
*SAME
*SAME
*SAME
T I N G
PDN
PDN
PDN
DVP
DVP
DVP
ITG
* *
MARKE
MARKE
MARKE
To
Environment
==============
PDN
PDN
PDN
PDN
PDN
PDN
PDN
DVP MARKE
DVP MARKE
DVP MARKE
ITG
ITG
ITG
ITG
* * *
Figure 50 - Display Development Log Report view 1
Reports DO 6-9


JULY
6, 2007
Page
1
11:04 AM Job

Subsets in effect:
Object . . . . . . .
Object type . . . .
Activity code . . .
User . . . . . . . .
Affects task . . . .
Release . . . . . .
Application . . .
Group . . . . .
Related releases . .
From date . . . . .
To date . . . . . .
Range in effect:
First entry printed
Last entry printed .
Object
==========
DEMOCBL1
DEMOCBL2
DEMOCBL3
DEMORPG1
DEMORPG2
DEMORPG3
CLNADRL
CLNADR
DEMOCBL1
DEMOCBL2
CLNADR
DEMOCBL1
DEMOCBL2
DEMOCBL2
Type
=====
*PGM
*PGM
*PGM
*PGM
*PGM
*PGM
*FILE
*FILE
*PGM
*PGM
*FILE
*PGM
*PGM
*PGM
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
:
:
:
. . :
. . :
*ALL
*ALL
*ALL
*ALL
*NA
BASE
ACMSDEMO
ALDON
*NONE
*FIRST
*LAST
*TOPSCREEN
*BOTSCREEN
Act
Release
Date
Time
Cde User
Task
Comment
======= ======== ======== === ========== ========== ==============================================
ACM/BAS
1/16/95 18:10:40 LOD MARKE
ACM/BAS
1/16/95 18:10:50 LOD MARKE
ACM/BAS
1/16/95 18:10:58 LOD MARKE
ACM/BAS
1/16/95 18:11:06 LOD MARKE
ACM/BAS
1/16/95 18:11:18 LOD MARKE
ACM/BAS
1/16/95 18:11:28 LOD MARKE
ACM/BAS
1/16/95 18:11:51 LOD MARKE
ACM/BAS
1/17/95
9:38:15 CHK MARKE
ACM/BAS
1/17/95
9:38:22 CHK MARKE
ACM/BAS
1/17/95
9:38:24 CHK MARKE
ACM/BAS
1/17/95 10:15:26 PRM MARKE
ACM/BAS
1/17/95 10:15:53 PRM MARKE
ACM/BAS
1/17/95 10:16:02 PRM MARKE
ACM/BAS
1/17/95 11:04:10 CRT MARKE
* * * * *
E N D
O F
L I S T I N G
* * * * *
Figure 51 - Display Development Log Report view 2
DO 6-10 Reports

Daily Operations
DO
Appendix A
Pseudo-Source
This appendix contains the following sections:

About Pseudo-Source on page DO A-2
Technical Details on page DO A-2
To determine whether an object is pseudo-source based on page
DO A-3
For additional information on setting up and using pseudo-source see:
Types of Objects Handled starting on page UG 1-5 in the Aldon LM(i)
Users Guide
Using Pseudo-Source, starting on page UG 2-16
Pseudo-Source Example, starting on page UG 2-16
Source Option and Pseudo-Source, starting on page UG 5-3
Working with Pseudo-Source, starting on page UG 5-6
To map pseudo-source objects in a library group starting on page
SA 16-6 in the Aldon LM(i) Setup and Administration Reference
Pseudo-Source DO A-1
About Pseudo-Source
For basic information on creating and using pseudo-source, see Working
with Pseudo-Source starting on page UG 5-6 in the Aldon LM(i) Users
Guide. This appendix provides additional information and technical
details.
The Aldon Lifecycle Manager for System i (Aldon LM(i)) pseudo-source
facility provides a way to store, retrieve, and use the information needed
to create CL based objects such as data areas, JOBDs, and SQL based
objects such as tables, indexes, and views.
An example of pseudo-source for a data area appears below:
Columns . . . :
1 71
Edit
MARKE/QCLSRC
SEU==> ____________________________________________________________ TESTDTAARA
*************** Beginning of data *************************************
0001.00 CRTDTAARA DTAARA(&LIB/TESTDTAARA) TYPE(*CHAR) LEN(3) +
0002.00
VALUE('ABC') TEXT('TEST PSEUDO-SOURCE') AUT(*ALL)
****************** End of data ****************************************
(C) COPYRIGHT IBM CORP. 1981, 1991.
Figure 52 - SEU panel for pseudo-source entry
Technical Details
When Aldon LM(i) creates an object from pseudo-source, it first creates
the object in a temporary library, then, if the create executes without
errors, the object is moved using CRTDUPOBJ into the designated
library replacing any previously existing copy.
SQL objects are handled differently because they cannot be moved after
creation. An SQL object is first created from pseudo-source in a
temporary library. If this create is successful, this temporary copy is
deleted. The final copy is then created in the destination library.
DO A-2 Pseudo-Source
When populating an SQL object into a data library there is no preceding

test create. Any previous copy of the SQL object in the data set is
deleted. Then Aldon LM(i) creates the new copy into the data set library.
Data sets are usually updated immediately after successful promotion of
the SQL object into the associated Aldon LM(i) environment library.
To determine whether an object is pseudo-source based


Developer panel.
object you want to investigate, type 8 (Display attributes) and press

to view details about the object.
ENTER
3. You will find the objects source type (normal, pseudo-source, or no
source) at the far right in the - - Source - - section under the Type
column heading.
Pseudo-Source DO A-3
DO A-4 Pseudo-Source

Daily Operations
DO
Appendix B
Menus as Aldon LM(i) Objects
This appendix describes how to work with System i menu objects in

Aldon Lifecycle Manager for System i (Aldon LM(i)). The following topics
are included:
Developing System i Menus with Aldon LM(i), starting on page DO B-1
Handling Menu Objects Using Non-Default Values, starting on page
DO B-3
Handling Menu Objects Using Pseudo-Source, starting on page DO B-8
Developing System i Menus with Aldon LM(i)

Menu Objects Outside of
Aldon LM(i)
Outside of Aldon LM(i), a System i menu exists as three objects based on two
source members:
Component
Corresponding Source Members
display file (*DSPF)
member type MNUDDS in QDDSSRC;

command list, member type MNUCMD
(also in QDDSSRC with suffix QQ)
Menus as Aldon LM(i) Objects DO B-1
Menu Objects Inside of

Aldon LM(i)
Component
Corresponding Source Members
menu object
(*MENU)
(no source)
message file
(*MSGF)
(no source)
The current version of Aldon LM(i) handles System i menu objects by

separately tracking the display file, display file command member, menu
object, and associated message file. When creating a new release from
objects outside of Aldon LM(i), you map or load each of these
components without taking any special steps.
Once inside Aldon LM(i), there are two methods of supporting the editing
and promotion of menu objects: the non-default value method and the
pseudo-source method.
The non-default value method requires users to type two non-default SDA
values each time they modify a menu in Development.
The pseudo-source method requires creation of a special pseudo-source
source member for a menu the first time a user modifies it in
Aldon LM(i), but requires no further special user action.
You may want to try both methods. If you find you are making frequent
menu modifications, and the extra steps required by the non-default value
method starts to impact efficiency, try converting a few menus to the
pseudo-source method to see if the time savings is worth the conversion
effort. We recommend that for long term use you rely on one method or
the other. Since the method in use for a particular menu is not visible on
the Work with... panels, you cannot directly determine which menus
use which methods and therefore, which menus require the extra value
entry step and which do not. See To determine whether an object is
pseudo-source based, starting on page DO A-3 for help in determining
the editing method currently in use for a *MENU object.
For information on the non-default value method, see Handling Menu
Objects Using Non-Default Values below.
For information on the pseudo-source method, see Handling Menu
Objects Using Pseudo-Source, starting on page DO B-8.
DO B-2 Menus as Aldon LM(i) Objects
Handling Menu Objects Using Non-Default Values

Under the non-default value method, the display file and command list
have normal source code; the menu object and the message file are
non-source objects inside of Aldon LM(i):
Component
Source Obtained From
member type MNUDDS in QDDSSRC
command list (*SRCMBR)

menu object (*MENU)
(no source)
message file (*MSGF)
(no source)
(*SRCMBR is an Aldon LM(i) defined data type containing source code

that is not directly compilable into an object.)
To add a System i menu

Add a System i menu to an application in Aldon LM(i) by performing
these steps:

Developer panel.
2. At the Work with Objects by Developer panel, press F6 (Add object)
to display the Add Release Object panel:

CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object name. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . .
Source option .
Source file .
Source member
Task . . . . . .
Comment for log
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400
Name
Type
+
Attribute
ILE, BND, OPM (*PGM) SQL (*FILE)
*
LINDAC
+
Name
1
QDDSSRC
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
Add display file for sample System i menu MENU400
*FILE
DSPF
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
3. At the Add Release Objects panel, complete values as shown above to
Add the Display File
add the display file with its existing display file source member
(MNUDDS). In this example, the member is contained in the file
QDDSSRC. Fill in the correct file name for your file.
Note
When you press ENTER, panels for selecting the object and source
library groups display. After you complete these panels, the Add
Release Objects panel redisplays. The instructions below assume you
are adding all component objects at the same time before returning to
the Work with Objects by Developer panel. You can perform these
object additions in any order, all at one time or at different times. See
Adding an Object starting on page UG 5-2 in the Aldon LM(i)
Users Guide for more detailed instructions on adding objects.
Add the Command List for the

Display File
4. At the Add Release Objects panel, add the command list for the
display file using Aldon LM(i) data type *SRCMBR as shown below.
The source file is usually the same as that containing the display file
added in the figure above.
CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . .
Source option .
Source file .
Source member
Task . . . . . .
Comment for log
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400QQ
Name
Type
+
Attribute
*
LINDAC
+
Name
1
QDDSSRC
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*SRCMBR
MNUCMD
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Add the *MENU Object without

Source
5. At the Add Release Objects panel, add the *MENU menu object as a
non-source object as shown below:
CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . .
Source option .
Source file .
Source member
Task . . . . . .
Comment for log
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400
Name
Type
+
Attribute
*
LINDAC
+
Name
9
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*MENU
DSPF
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Add the Menu Message File
6. At the Add Release Objects panel, add the menu message file as a
non-source object as shown below:

CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . .
Source option .
Source file .
Source member
Task . . . . . .
Comment for log
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400
Name
Type
+
Attribute
*
LINDAC
+
Name
9
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*MSGF
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
To edit a menu
To work with a System i menu, check out and promote the display file,
command list, menu, and menu message file together at the same time.
You must use this procedure each time you modify a *MENU object
created without pseudo-source. If you do not use this procedure, the menu
will fail to work when promoted out of Development.
1. At the Aldon LM(i) main menu, type option 1 and press ENTER to
display the Work with Objects by Release panel.

2. At the Work with Objects by Release panel, in the Opt fields by the
display file, command list, menu, and message file, type option 3
(Check out) and press ENTER to check the menu component objects
out to development.
3. Complete the checkout in the standard manner. See the Checking
Out Objects, starting on page UG 2-10 for assistance if necessary.

4. At the Work with Objects by Release panel or Work with Objects by
Developer panel, in the Opt field by the *FILE object, type option 19
(AltEdit) and press ENTER to edit the menu with SDA.
5. Edit the menu in SDA in the usual manner.
6. In SDA, after you are finished editing the menu, exit to display the
Exit SDA Menus panel:

Exit SDA Menus
File . . . . . . :
Library . . . . :
QDDSSRC
DEBM
DDS member . . . . . :
Commands member . . . :
TESTLIBL
TESTLIBLQQ

Save new or updated menu source . . . .
For choice Y=Yes:
Source file . . . . . . . . . . . .
Y=Yes, N=No
QDDSSRC
Library . . . . . . . . . . . . .
Text . . . . . . . . . . . . . . . .
DEBM
Name,
F4 for list
Name, *LIBL, *CURLIB
Replace menu members . . . . . . . .
Y=Yes, N=No
. . . . . . .
Y=Yes, N=No
. . . . . . .
. . . . . . .
. . . . . . .
Y
DEBM
Y
Y=Yes, N=No
Name, *CURLIB
Y=Yes, N=No
Create menu objects . . .

For choice Y=Yes:
Prompt for parameters
Object library . . . .
Replace menu objects .
F3=Exit
F4=Prompt
F12=Cancel
7. In the Prompt for parameters field, type Y (Yes) and press ENTER to
display the Create Menu panel:

Create Menu (CRTMNU)
Menu . . . . . . . . .
Library . . . . . .
Menu type . . . . . .
Display file . . . . .
Library . . . . . .
Message file . . . . .
Library . . . . . .
Command line . . . . .
Display function keys
Current library . . .
Product library . . .
Replace menu . . . . .
Text description . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F3=Exit
F4=Prompt
F5=Refresh
F13=How to use this display
MENU400
DEBM
*DSPF
MENU400
*LIBL
MENU400
*LIBL
*LONG
*YES
*NOCHG
*NOCHG
*YES
*BLANK
Name
Name, *CURLIB
*DSPF, *PGM, *UIM
Name,*MENU
Name, *MENU
*LONG, *SHORT, *NONE
*YES, *NO
Name, *NOCHG, *MNULIB...
Name, *NOCHG, *NONE
*YES, *NO
F10=Additional parameters
F24=More keys
Bottom
F12=Cancel
8. At the Create Menu panel, in the Display file and Message file
Library fields, type *LIBL and press ENTER.

Note
This procedure creates the *MENU object with the library value
*LIBL coded in the object description for the location of the display
file and message file. When you promote the menu components to a
new environment, Aldon LM(i) uses the CRTDUPOBJ command to
accomplish the promotion. Because the *MENU object description
that is moved specifies *LIBL, the components in the new
environment library will be referenced by the *MENU object rather

than those in the developer library where the *MENU object was
created.
Developer panel, in the Opt field by each of the four menu object
components, type 7 (Promote) and press ENTER to promote the
objects from Development to the next environment.
10. Repeat Step 9 as necessary until the components reach Production.
Handling Menu Objects Using Pseudo-Source

When handling menu objects using pseudo-source, the display file and
command list have normal source code, the menu object is based on
pseudo-source, and the message file is a non-source object:
Component
Source Obtained From
member type MNUDDS in QDDSSRC
command list (*SRCMBR)

menu object (*MENU)
pseudo-source created by user
message file (*MSGF)
(no source)
(*SRCMBR is an Aldon LM(i) defined data type containing source code

that is not directly compilable into an object.)
To add a System i menu using pseudo-source

1. At the Aldon LM(i) main menu, type option 2 and press ENTER to
display the Work with Objects by Developer panel.
2. At the Work with Objects by Developer panel, press F6 (Add object)
to display the Add Release Object panel:

CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object name. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . . . . . .
Source option . . . . .
Source file . . . .
Source member . . .
Task . . . . . . . . . .
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400
Name
Type
+
Attribute
ILE, BND, OPM (type *PGM only)
*
LINDAC
+
Name
1
QDDSSRC
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*FILE
DSPF
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Figure 53 - Add Menu Display File Using Add Release Objects Panel
3. At the Add Release Objects panel, complete values as shown in
Add the Display File
Figure 53 to add the display file with its existing display file source
member (MNUDDS). In this example, the member is contained in the
file QDDSSRC. Fill in the correct file name for your file.
Note
When you press ENTER, panels for selecting the object and source
library groups display. After you complete these panels, the Add
Release Objects panel redisplays. The instructions below assume you
are adding all component objects at the same time before returning to
the Work with Objects by Developer panel. You can perform these
object additions in any order, all at one time, or at different times. See
Adding an Object starting on page UG 5-2 in the Aldon LM(i)
Users Guide for more detailed instructions on adding objects.
Add the Command List for the

Display File
CADDOBJ
Add Release Object

Release . . . . .
Application . .
Group . . . .
Object name . . . .
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . . . . . .
Source file . . . .
Source member . . .
Task . . . . . . . . . .
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400QQ
Name
Type
+
Attribute
*
LINDAC
+
Name
1
QDDSSRC
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*SRCMBR
MNUCMD
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Figure 54 - Add Menu Commands List Using Add Release Object Panel
4. At the Add Release Objects panel, add the command list for the
display file using Aldon LM(i) data type *SRCMBR as shown in

Figure 54. The source file is usually the same as that containing the
display file added in Figure 53.
Add the *MENU Menu Object.
CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object name .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . . . . . .
Source file . . . .
Source member . . .
Task . . . . . . . . . .
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400
Name
Type
+
Attribute
*
LINDAC
+
Name
2
PSEUDOSRC
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*MENU
DSPF
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Figure 55 - Add *MENU Object Using Add Release Object Panel
5. At the Add Release Objects panel, add the *MENU menu object with
its pseudo source as shown in Figure 55. For the source file, enter the
file to contain the pseudo source member which you will create in
Step 6 below. The source file and member need not exist when you
add the *MENU menu object.
We recommend using a source file other than QDDSSRC to contain
the pseudo-source. You might want to use the name PSEUDOSRC
Note
Create Pseudo-Source for the

*MENU Object
6. Using SEU or another source editor, create pseudo-source for the
Note
*MENU menu object as shown in Figure 56. Save the member in a

file with a name such as PSEUDOSRC.
Aldon LM(i) uses the &LIB pseudo-source parameter to specify the
correct library to contain the menu based on the environment the
object is created in instead of basing creation on the System i
description of the object which lists the library the object was last
created in. See Working with Pseudo-Source starting on page
UG 5-6 in the Aldon LM(i) Users Guide and Pseudo-Source,
starting on page DO A-1 for more information on using
pseudo-source.
Columns . . . :
1 71
Edit
LINDAC/PSEUDOSRC
SEU==> ____________________________________________________________
MENU400
0001.00
CRTMNU
MENU(&LIB/MENU400) TYPE(*DSPF)
****************** End of data ****************************************
(C) COPYRIGHT IBM CORP. 1981, 1991
Figure 56 - Create Pseudo-Source Member for *MENU Object Using SEU
Add the Menu Message File
7. At the Add Release Object panel, add the menu message file as a
non-source object as shown in Figure 57.

CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object name. .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
Developer . . . . . . .
Source file . . . .
Source member . . .
Task . . . . . . . . . .
BASE
+
Name
ACMSDEMO
+
Name
ALDON
+ Name
MENU400
Name
Type
+
Attribute
*
LINDAC
+
Name
9
Name
*SYSOBJNAM
Name, *SYSOBJNAM
+
Name
*MSGF
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Figure 57 - Add Menu Message File Using Add Release Object Panel
Developer panel, in the Opt field by the *FILE object, type option 19
(AltEdit) and press ENTER to edit the menu with SDA.
9. Edit the menu in SDA in the usual manner.
Working With Pseudo-Source Based System i

Menus
To work with a pseudo-source based System i menu, check out and
promote the display file, command list, menu, and menu message file
together at the same time.
When you want to modify a menu object for the first time, you create
pseudo-source for the *MENU object component and use the Change
Object Description panel to associate this pseudo-source with the object
in the Aldon LM(i) database.
To modify a pseudo-source based System i menu object

for the first time
With the pseudo-source method, the first time you modify a System i
menu object after mapping or loading it you must create the
pseudo-source. After that you just need to check out and promote the four
components together.
panel.
2. At the Work with Objects by Release panel, in the Opt column, select
the display file, command list, menu, and menu message file with
option 3 (Check out) and press ENTER to check the menu component
objects out to development.
3. Complete the checkout in the standard manner. See the Checking
Out Objects, starting on page UG 2-10 for assistance if necessary.

Create Pseudo-Source for the
*MENU Object
4. Using SEU or another source editor, create pseudo source for the
*MENU menu object as shown in Figure 58.

Aldon LM(i) uses the &LIB pseudo-source parameter to specify the
correct library to contain the menu based on the environment the
object is created in instead of basing creation on the System i
description of the object which lists the library the object was last
created in. See Working with Pseudo-Source starting on page
UG 5-6 in the Aldon LM(i) Users Guide and Pseudo-Source,
starting on page DO A-1 for more information on using
pseudo-source.
Columns . . . :
1 71
Edit
LINDAC/PSEUDOSRC
SEU==> ____________________________________________________________
MENU400
0001.00
CRTMNU
MENU(&LIB/MENU400) TYPE(*DSPF)
****************** End of data ****************************************
(C) COPYRIGHT IBM CORP. 1981, 1991
Figure 58 - Create Pseudo-Source Member for *MENU Object Using SEU
5. In Aldon LM(i), at the Work with Objects by Developer panel, in the
Opt field by the *MENU object, type 16 (Change object) and press
ENTER to display the Change Checked Out Object panel:
CCHGOBJ
Change Checked Out Object
Object . . . . . . . . . :
MENU400
Release . . . . . . . . :
Developer . . . . . . . :
ALDON/ACMSDEMO/BASE
LINDAC

Object type . . .
Object attribute .
Extended attribute
Data option . . .
Source option .
Source file .
Source member
Source library
.
.
.
.
.
.
.
.
:
:
:
.
*MENU
DSPF
. . .
. . .
. . .
group
.
.
.
.
2
PSEUDOSRC
MENU400
2 +

Command ===>
F3=Exit
F4=Prompt
F9=Retrieve

Name
Name
Library group number
F12=Cancel
F22=More functions
6. At the Change Checked Object panel, in the Source option field, type
option 2 (Pseudo-source)
7. In the Source file, and Source member fields, type the name of the
file and member containing the pseudo-source created in Step 4.

8. In the Source library group field, type the number of the library
group to hold source for the object and press ENTER.

You can press F4 to select the library group from a list.
Tip
9. At the Work with Objects by Developer panel, select the *MENU
object with option 19 (AltEdit) to modify the menu using SDA.

10. Promote the display file, command list, menu, and menu message file
objects.

Daily Operations
DO
Appendix C
Record Objects
*RCDS objects are introduced in the section titled *RCDS Objects starting
on page UG 5-2 in the Aldon LM(i) Users Guide.
This chapter includes the following topics:
Overview, starting on page DO -2
*RCDS Object Limitations and Requirements, starting on page DO -3
Defining Record Objects, starting on page DO -5
Controlling *CONTAIN File Creation Options, starting on page DO -9
Working with *RCDS Objects, starting on page DO -11
Working with Underlying Files, starting on page DO -13
How Aldon LM(i) Manages the Physical and Logical Files, starting on
page DO -13
*RCDS Objects in Multiple-Release Applications, starting on page
DO -12
Record Objects DO C-1
Overview
The Purpose of Record Objects
Aldon Lifecycle Manager for System i (Aldon LM(i)) provides a facility
for defining a range of records as an object. Once defined, a records
object, indicated by the Aldon defined type *RCDS, may be checked out,
modified, and promoted like any other object in Aldon LM(i).
How Record Objects Work
Define a *RCDS object over one or more keyed files which serve as
base files. For each *RCDS object, identify the range of records in each
base file which together comprise the object.
You define a new *RCDS object over base files defined to the release and
present only in Production. The *RCDS object definition in the
Aldon LM(i) object database identifies the range or ranges of records that
constitute the object. You use the Aldon LM(i) Add Object function to
add the *RCDS object and specify a developer in the process.
When you define a new *RCDS object, Aldon LM(i) creates any required
logical or physical files in the developer object library if they are not
already present. If Aldon LM(i) creates new files it also copies the
specified range of records to the files from the Production files on which
the *RCDS object is based.
If the required files are already present in the developer object library,
Aldon LM(i) does not copy records. This protects any records which may
have been created or modified by the developer. You can copy records to
the developer library files from Production using your standard file
handling tools and techniques outside of Aldon LM(i) if necessary.
In the developer library, you modify, add, or delete records within the
identified ranges as necessary. Promote the *RCDS object using standard
Aldon LM(i) promote options. Aldon LM(i) ignores changes to records
outside the ranges specified for the checked out *RCDS object at promote
time.
For subsequent modifications, you check the *RCDS object out using
standard Aldon LM(i) checkout options. Aldon LM(i) creates the file in
the developer library if necessary and copies records from the appropriate
Aldon LM(i) controlled environment for modification.
DO C-2 Record Objects
What Aldon LM(i) Does When You Define a *RCDS Object

If you define a *RCDS object using the Aldon LM(i) panel interface,
Aldon LM(i) always defines the new *RCDS object as present in the
Development environment. (If you define a *RCDS object using the
ACMSADDOBJ command, Aldon LM(i) supports definition of *RCDS
objects in either the Development environment or the Production
environment.)
If you define a new *RCDS object in the Development environment
Aldon LM(i) creates a database entry for the *RCDS object

placing the object in the Development environment
Aldon LM(i) creates any required files not already present in

Development and copies the defined range of records to those
files. If files are already present records are not copied. This
protects changes or additions made by the developer.
When you define the first *RCDS object over a file, Aldon LM(i)
Changes the Aldon LM(i) object type of the base file or files from
*FILE to the special Aldon LM(i) object type *CONTAIN
throughout the application
If a base file is a logical file, Aldon LM(i) converts both the logical
and the physical file it is over to type *CONTAIN
Library Groups and *RCDS Objects

When you define a *RCDS object you assign it to an object library group.
The library group is used to select the *RCDS for deployment and to
determine where *CONTAIN files are placed in deployment targets and in
the production environment.
Because *RCDS objects are not source based, no source library group is
defined.
*RCDS Object Limitations and Requirements

Requirements and Limitations for the Underlying
Files
The file directly referenced in the *RCDS object definition must be
keyed.
Numeric keys used in files on which *RCDS objects are based must be
defined as UNSIGNED. Aldon LM(i) uses the CPYF command to
manipulate *RCDS objects. Because of limitations in how the CPYF
command handles record sorting, any numeric key fields in physical or
logical files used to define *RCDS objects must be defined as
UNSIGNED in the file description DDS. This overrides the default

field type of SIGNED which causes sorting problems when moving
records between files. Other sequencing keywords should not be used.
If a keyed logical file is used to accesses a physical file,
The logical file must be the only logical over the physical file,
The logical file must not be over any other physical files, and
The physical file must not have already been converted to type
*CONTAIN (already in use by a *RCDS object)
The *FILE or files used as the base for a *RCDS object must be
defined to Aldon LM(i)
The *FILE must be in an activated release
All copies of the *FILE object in the application must be in the
Production environment (the *FILE object cannot have any active
copies (copies in Development, Integration or Quality Assurance), in
any release of the application)
The *FILE object also cannot be included in any non-finished
deployment sets
Requirements and Limitations for *RCDS Objects

Files over which *RCDS objects are defined must be type
*CONTAIN, or *FILE objects eligible for conversion to type
*CONTAIN as defined above in Requirements and Limitations for
the Underlying Files
Ranges of records specified for *RCDS objects cannot overlap
In the current release of Aldon LM(i), all records for a record object in
a given file must be contained in a single key range
A given physical file may be used as the basis for *RCDS objects
directly or through at most one logical file
A logical file used as a base for *RCDS objects may be over no more
then one physical file
*RCDS objects cannot be built over physical files that have Data
Option set to option 2 (Promote data). Physical files must have Data
Option set to option 1 (Keep destination data).
Defining Record Objects

To define files to Aldon LM(i) for use by *RCDS objects
Map or Load files on which *RCDS objects will be based as you would
any other object when populating a new release. New files added to a
release using the add object function can also be used as the basis for
*RCDS objects.
Note
*RCDS objects cannot be built over physical files that have Data Option
set to option 2 (Promote data). Physical files must have Data Option set to
option 1 (Keep destination data).
For additional information on mapping and loading files at release
definition see Population Functions Overview starting on page SA 15-1
in the Aldon LM(i) Setup and Administration Reference.
For additional information on adding new files to a release see Adding
an Object starting on page UG 5-2 in the Aldon LM(i) Users Guide
To define a *RCDS object

Prerequisite
The release must be activated.

1. At the Aldon LM(i) main menu, type 1 to display the Work with
Objects by Release panel.

2. At the Work with Objects by Release panel, press F6 (Add object) to
display the Add Release Object panel.
Note
*RCDS objects may also be defined using F6 from the Work with Objects
by Developer panel or the ACMSADDOBJ command discussed in
Command Interface, starting on page CG 7-1.
CADDOBJ
Add Release Object

Release . . .
Application
Group . .
Object name .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
BASE
MARK1
MARKE
TESTOBJ
Object type . . .
Object attribute .
Extended attribute
Data option . . .
.
.
.
.
.
.
.
.
.
.
.
.
*RCDS
Developer . . . .
Source option . .
Source file .
Source member
Task . . . . . . .
Comment for log .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
+
+
+
+
*
MARKE
9
*SYSOBJNAM
+
Name
Name
+ Name
Name
Type
Attribute
Name
Name
Name, *SYSOBJNAM
Name
Command ===> __________________________________________________________________

F3=Exit
F4=Prompt
F7=Add task
F12=Cancel
F24=More keys
Figure 59 - Add Release Object Panel (for *RCDS object)

3. At the Add Release Object panel
a.
In the Object name field, type a name for the *RCDS object
b.
In the Object type field, type *RCDS
c.
In the Developer field, type the name of the developer definition

for the developer who will first work with the object.
d.
In the Source option field, type 9 (None). *RCDS objects must

be no source.
e.
Work with the Task and Comment for log fields as desired.
4. Press ENTER to check the values entered. If all values are correct, the
Define *RCDS Object panel displays:

CADDOBJRCD
Define *RCDS Object

Object text
. . . . . .
More:
File name . . . . . .
Member name . . . . .
Copy from record key:
Number of key fields
Key value . . . . .
.
.
KEYEDPF
*FIRST
. .
. .
1
00001
Name
Name, *FIRST
Number
Character value
Copy to record key:
Number of key fields . .
Key value . . . . . . .
1
00002
Number
Character value
Command ===> __________________________________________________________________
_______________________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F22=More functions
Figure 60 - Define *RCDS Object Panel

5. At the Define *RCDS Object panel, in the Object text field, type
descriptive text for the *RCDS object as desired.

6. Identify the location of the first desired record range by doing the
following:
a.
In the File name field, type the name of the keyed physical or
logical file.
b.
In the Member name field, type the name of the file member.
7. Under Copy from record key, identify the first record of the record
range by doing the following:

a.
In the Number of key fields field, specify the number of key

fields to use in selecting the starting record. Enter 1 to use only
the first key of the file. Enter 2 to use the first and second key
fields etc.
b.
In the Key value field, type the character string specifying the
actual key values for the first record of the range.
Specify the key string in quotation marks if it contains blanks,
lower-case letters, or special characters.
You can specify the key value in hexadecimal format if you
desire. Specifying key values in hexadecimal is useful for
ensuring selection of all records in a file (x'00' thru x'FF'), or if
the key contains packed decimal or binary numeric fields or is a
variable-length character field.
Hexidecimal key values
Note
CCSID (coded character set identifier) conversions are not

performed on character fields when a single string is specified.
8. Under Copy to record key: identify the last record of the record
range in the same fashion as for the from record described above in
Step 7.
9.
If you wish to include record ranges from additional files, press PAGE
DOWN (ROLL UP) to display additional fields for identifying files,
members and key ranges. Specify each additional range using Step 6
through Step 8 above.
10. Press ENTER.
The Select Library Group for Object panel displays.

11. At the Select Library Group for Object panel, in the Opt field by the
desired library group, type 1 (Select).

Note
The object library group for a *RCDS object is used for the purpose
of selecting the object for update into a data set or for determining
eligibility for deployment. If deployed, the object data library also
determines the installation location of the *CONTAIN file or files for
the deployed record range.
12. Press ENTER to add the *RCDS object.
Aldon LM(i) checks to see if the required file or files are present in
the object library of the identified developer. If the files are present,
Aldon LM(i) does not copy the record range from Production. If the
files are not present, Aldon LM(i) creates the required files and copies
the designated records to the files from the Production copies of the
files.
Aldon LM(i) changes the type of the production files to *CONTAIN
and sets the default values to control file replication. For information
on controlling file replication see Controlling *CONTAIN File
Creation Options, starting on page DO C-9.
13. If the files were already present in Development, outside of
Aldon LM(i) copy the necessary record range to the file or files in the
developer library for the developer specified in Step 3c above.
14. Edit the record range of the *RCDS object in Development as desired.
Note
Later, when you check out an existing *RCDS object for further
modification, Aldon LM(i) copies the specified record range to
Development.
To define a *RCDS object over an unkeyed physical file

Use the following procedure to include records from an unkeyed physical
file in a *RCDS object.
1. Define a keyed logical file over the unkeyed physical file.
2. Define the *RCDS object over the keyed logical file.
Controlling *CONTAIN File Creation Options

Aldon LM(i) provides two parameters to control the replication and
persistence of a *CONTAIN file upon which *RCDS objects are based:
Populate only requested records
Keep container file in all environments
You can set these parameters individually for each *CONTAIN file in a
release. The values you select in one release need not match for copies of
the same *CONTAIN file in different releases of an application. These
values control the extent and persistence of the base files in controlled
active environments (Development, Integration, and Quality Assurance).
Populate only requested records
This setting controls whether Aldon LM(i) copies all or just a portion of
the base file when placing the base file in controlled active environments
to support promotion of *RCDS objects defined over it.
Select Y to move only the range of records specified in *RCDS objects
selected for promote. If the file is not in Development, an empty copy of
the *CONTAIN is created and the range of records defined by the *RCDS
object is copied to Development.
Select N to include all records in the *CONTAIN file in each environment
into which you promote the *RCDS objects. A full copy of the contain
file is created in Development.
Keep container file in all environments
This setting tells Aldon LM(i) when to delete copies of the *CONTAIN
file from controlled active environments.
Select Y to leave the *CONTAIN file behind in controlled active
environments when the last *RCDS object over it leaves the environment.
With this setting, Aldon LM(i) leaves the *CONTAIN file in controlled
active environments as long as a *RCDS object is defined over the base
file in any release of the application.
Select N to delete the *CONTAIN file from a controlled active
environment as soon as the last *RCDS object over the base file leaves
that environment.
Discussion
Testing may require the presence of a complete copy of the file on which a
*RCDS object is based in the test environment. Promote the changed
*RCDS object to the test environment with full replication selected if this
is the case.
If testing requires a complete copy of the base file, and the file is quite
large, you may wish to avoid time consuming file copying by leaving the
file in the various environments even when it is not required by the
presence of *RCDS objects.
To control *CONTAIN file replication and persistence


2. At the Work with Objects by Release panel, type 15 by the physical
file *CONTAIN object you want to work with to display the Change
*CONTAIN Creation Options panel.
CCHGCRTCON
Change *CONTAIN Creation Options
Release . . . .
Object name . .
Object type . .
Object attribute
.
.
.
.
.
.
.
.
:
:
:
:
ALDON/ACMSDEMO/BASE
CLNADRL
Environment . . . . :
*CONTAIN
Object library . . . :
LF
Populate only requested records . . .

Keep container file in
all environments . . . . . . . . .
Y=Yes, N=No
Y=Yes, N=No
PDN
ACMBASPDN1
Command ===>
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
Figure 61 - Change *CONTAIN Create Options Panel

3. At the Change *CONTAIN Creation Options panel, in the Populate
only requested records field, do the following:
To populate only requested records, type Y
To populate the complete file, type N
4. In the Keep container file in all environments field, do the
following:
Note
To leave a copy of the container file behind after the last *RCDS
object over it leaves the environment, type Y
To delete the container file when the last *RCDS object over it
leaves the environment, type N
If the *RCDS object is defined over more than one physical file, you can
change the creation options independently for each *CONTAIN object
corresponding to a physical file.
Working with *RCDS Objects

Work with *RCDS objects using the same options, functions, and
commands as standard objects.
Checkout, emergency checkout, inclusion in tasks, archiving, object
version numbering, and object deployment all apply to *RCDS objects
in the same fashion as objects of other types.
When you check out a *RCDS object, Aldon LM(i) copies the
complete *CONTAIN file to Development. This is true regardless
what options you choose to control *CONTAIN file replication.
First time promotion of a newly defined *RCDS object requires the
presence of the underlying file or files in your developer object library.
If they are not already present in the Development environment,
Aldon LM(i) places these files in your developer library automatically
and copies the defined record range into them from Production when
you define the *RCDS object. If the files are already present, you must
manually (outside of Aldon LM(i)) copy the defined record range from
Production if necessary. You will not be able to promote the *RCDS
object until these files and the defined record range are in place.
Perform all subsequent promotions of the *RCDS object in the same
fashion as objects of other types.
Aldon LM(i) treats *RCDS objects as program objects as opposed to
data file objects. You can map the library group containing a *RCDS
object to a data set library. Aldon LM(i) updates the new *RCDS
object (its specified range of records) in the data set. Since it is not a
data object, Aldon LM(i) does not preserve the data in any replaced
copy in the data set library.
For *RCDS objects, you define an object library group but no source
library group. Aldon LM(i) uses the object library group only to
decide whether or not the *RCDS object is eligible for update into a
deployment target, can be deployed using a given deployment profile,
and what library to install it in for a given deployment target. The
underlying files may be in any library defined to Aldon LM(i) for the
Production environment. When you deploy a *RCDS object, the
library group of the *RCDS object determines the target library to
receive the underlying file or files.
The range of records defined in *RCDS objects cannot be changed.
You must delete the object and add a new one.
The ACMSCHKFRN command does not handle *RCDS objects.
*CONTAIN objects cannot be checked out with any function or
command.
Warning
Modification of files on which *RCDS objects are based within

Integration, Quality Assurance or Production by a user program is
contrary to the design of Aldon LM(i) and may cause unexpected results.
To stop handling records with *RCDS objects

To stop handling the records contained in *RCDS objects with
Aldon LM(i), do the following:
1. Promote all *RCDS objects defined over a given file to Production.
2. Delete all *RCDS object definitions over the *CONTAIN files by
To Delete *RCDS Objects
doing the following:

a.
At the Work with Objects by Release panel, in the Opt field by

the *RCDS objects you want to delete, type option 4 (Delete)
b.
Press ENTER.
Records within the *RCDS objects are not affected by deletion of the
*RCDS object definition. When the last *RCDS object definition is
deleted, the types of the files on which they are based change from
*CONTAIN to *FILE.
3. After converting all relevant *CONTAIN objects back to *FILE
objects, the records may be modified in Production by a user program

without conflict.
To view or print a *RCDS record range description


2. At the Work with Objects by Release panel do one of the following:
To display the record range, type 8 (Display attributes) by a

*RCDS object
To print a description of the record range, type 6 (Print source) by

a *RCDS object
*RCDS Objects in Multiple-Release Applications

On addition of a new *RCDS object or checkout of an existing *RCDS
object to a release that does not contain the underlying *CONTAIN files,
Aldon LM(i) copies the *CONTAIN files and any logicals over them to
the Production environment of that release.
Note
When Aldon LM(i) creates *CONTAIN files in a descendent release to

support a *RCDS object checked out to that release from an ancestor
release it carries forward any *CONTAIN file creation options which may
have been set for the parent release copies of these files. Set these options
on the files in the descendent release using the procedure described in To
control *CONTAIN file replication and persistence on page DO C-10.
Working with Underlying Files

Files converted to type *CONTAIN cannot be checked out for
modification.
The only actions allowed for a *CONTAIN file are:
Modification of the replication and persistence settings as described in
Controlling *CONTAIN File Creation Options
Conversion back into a normal *FILE object by deleting all overlying
*RCDS definitions
To convert a *CONTAIN file back to type *FILE

1. Promote all *RCDS objects over the *CONTAIN object to
Production.
2. Delete the definitions of all *RCDS objects over the *CONTAIN
object.
The *CONTAIN object converts the object back to type *FILE in all
releases of the application.
Note
Deletion of *RCDS objects leaves the records identified in the *RCDS

object definition intact and unchanged in the base files.
How Aldon LM(i) Manages the Physical and Logical

Files
Aldon LM(i) treats files on which *RCDS objects are based in a way
somewhat similar to the way it handles files containing source for
standard objects. System i constraints require that if an executing
application uses several *RCDS objects based on a given file, all *RCDS
objects must be obtained from the same file in the same library. To meet
this requirement while allowing multiple test environments, Aldon LM(i)
creates and manages phantom copies of a file in each Development or
test environment containing a *RCDS object based on it. If the file is a
logical file, it is accompanied by a phantom copy of its corresponding
physical file. Phantom files do not appear on displays.
The Production copies of the base files remain visible on displays of
release objects, but are identified with a special Aldon defined type,
*CONTAIN, and are not available for checkout or deployment.
For the first promotion, Aldon LM(i) creates new copies of the physical
file members in the receiving environment using data from the Production
copies of the files. If necessary, files to contain the members are also
created along with any logical files used. The identified ranges of records
from the Development files are then overlaid into these files. For the first
promotion into a second test environment, physical and logical files are
again copied from the Production environment and then overlaid with the
specified ranges of records. For promotion into Production, the files and
members already exist and only the records for the *RCDS object are
moved.
Promotion of a subsequent *RCDS object into an environment that
already contains *RCDS objects defined over the same file members
overlays records for the new object into the existing file members which
contains records for the previously promoted record objects. When a
*RCDS object is promoted out of an environment which still contains
*RCDS objects from the same files, copies of the records for the
promoted object remain behind for testing with the other *RCDS objects.
New copies of the records are created in the environment into which the
object is promoted. Promotion of the last *RCDS object out of a
Development or test environment may or may not cause Aldon LM(i) to
delete the underlying members and files depending on the setting of Keep
container file in all environments in the *CONTAIN file creation
options for each *CONTAIN object. (For details, see Controlling
*CONTAIN File Creation Options, starting on page DO C-9.)
Daily Operations Reference For System i Servers

Daily Operations
DO
Appendix D
PDM-Style User Options
About PDM-Style User Options

PDM-style user options provide a convenient way to perform actions on items
selected from a list. An option definition identifies the command to perform
the action, and maps data from the item list to the command parameters using
substitution variables. To use an option, type characters identifying the option
on the option line by the desired item and press Enter. The option processing
program substitutes information regarding the selected item into the command
for the option and then executes the completed command. Values not available
through substitution may be completed manually by prompting with F4.
Aldon provides user-defined options for checking out, creating, and
promoting objects from PDM (IBM's Program Development Manager). These
options work from both source member and object lists in PDM, and also
from source member and object lists within Abstract/Probe+ from
Advanced Systems Concepts (ASC) or Hawkeye's Pathfinder. Aldon LM(i)
also supports the use of PDM-style options created by the user or other
vendors on several panels within the Aldon LM(i) panel interface.
Aldon LM(i) enforces the same user authorities and release defined
requirements when processing actions ordered with user-defined options as it
does for actions initiated with the standard Aldon LM(i) panel interface. A
user can only perform checkout, build, and promote operations with
user-defined options if they are authorized to perform these functions within
Aldon LM(i). For example, if a release requires inclusion of objects in tasks,
or entry of a comment at checkout, Aldon LM(i) enforces these rules for
option generated checkouts just as it does for checkouts generated within
Aldon LM(i).
PDM-Style User Options DO D-1
This appendix describes how to set up Aldon provided user-defined

options for use with PDM, ASC's Abstract/Probe+, and Hawkeye's
Pathfinder, and how to set up user or third party provided options for use
with the Aldon LM(i) panel interface. This appendix assumes basic
familiarity with PDM and Aldon LM(i).
Aldon Option Setup

PDM options for Aldon LM(i) are deployed in a file named QAUOOPT
in the library ACMSLIB. Some of these options are also included by ASC
and Hawkeye in the user options file deployed with their products. The
next section discusses Aldon option setup for ASC's Abstract/Probe+ and
Hawkeye's Pathfinder. Subsequent sections describe installation of the
options for use with PDM from the file supplied by Aldon with
Aldon LM(i).
Aldon Option Setup for Abstract/Probe+ and

Pathfinder
This section applies only to Aldon LM(i) users who also use ASC's
Abstract/Probe+ or Hawkeye's Pathfinder for cross referencing and
documentation.
ASC and Hawkeye now includes several Aldon options in their option
file. Activate the option file as described by the vendor's documentation.
If the file includes the Aldon options, setup is complete.
Earlier copies of the option file received from your vendor do not include
Aldon LM(i) options. Contact ASC or Hawkeye for a new copy of this
file, or hand key the Aldon options using the Add function within PDM's
option 9 Work with user defined options function. Do not merge Aldon
options into the existing third party file with CPYF as described below.
Merging Aldon's option file with an existing options file results in a
non-alphabetized file. PDM supports non-alphabetized option files but
third party vendors may require that the file be alphabetized by option
code. Aldon options merged into an existing option file may not be
accessible to the third party vendor's program.
DO D-2 PDM-Style User Options
Aldon Option Setup for PDM

To copy Aldon options
Use the System i copy file command to copy the Aldon option file to a
new file or append it to an existing user-defined option file.
The following example command appends the Aldon options to the file
YOURFILE in library YOURLIB if such a file exists.
Example:
CPYF FROMFILE(ACMSLIB/QAUOOPT)
TOFILE(YOURLIB/YOURFILE)
MBROPT(*ADD) CRTFILE(*YES)
Note
The command creates the file if it does not already exist.
To activate Aldon options

Create the options file or merge the Aldon options into an existing options
file as described in To copy Aldon options above.
Prerequisites
1. Sign on with your user profile.

2. Start PDM by executing the following command:
STRPDM
The PDM main menu displays.

3. At the PDM main menu, press F18 (Change Defaults) to display the
Change Defaults panel:

Change Defaults
Object library . . . . . . .
Replace object . . . . . . .
*SRCLIB
N
Name, *CURLIB, *SRCLIB

Y=Yes, N=No
Compile in batch
Run in batch . .
Job description
Library . . .
Y
N
QBATCH
*LIBL
Y=Yes, N=No
Y=Yes, N=No
Name, *USRPRF, F4 for list
Name, *CURLIB, *LIBL
Change type and text . . . .
Y=Yes, N=No
Option file . . . . . . . .
Library . . . . . . . . .
Member . . . . . . . . . . .
QAUOOPT
QGPL
QAUOOPT
Name
Name, *CURLIB, *LIBL
Name
Full screen mode . . . . . .
Y=Yes, N=No
F3=Exit
.
.
.
.
.
.
.
.
F4=Prompt
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
F5=Refresh
F12=Cancel
Figure 62 - IBM PDM Change Defaults Panel
4. At the Change Defaults panel identify the options file containing the
options by doing the following

a.
In the Option file field, type the name of your options file.
b.
In the Library field, type the name of the library containing

your options file.
c.
In the and Member field, type the name of the member

containing your options.
Example: Figure 62 identifies the options file QAUOOPT in library

QGPL.
5. Press ENTER to return to the main PDM menu.
6. At the PDM main menu, type option 9 (Work with user-defined
options) and press ENTER.

The Specify Option File to Work With panel (not shown) displays
with the default options file filled in.
7. Press ENTER to proceed to the Work with User-Defined Options panel:
Work with User-Defined Options
File . . . . . . . :
Library . . . . :
QAUOOPT
QGPL

2=Change
3=Copy
Opt
_
_
_
_
_
_
_
_
_
Option
B
C
G
P
Q
R
BG
CG
PG
Command
/* ACMS
/* ACMS
/* ACMS
/* ACMS
/* ACMS
/* ACMS
/* ACMS
/* ACMS
/* ACMS
Member . . . . . . :
4=Delete
Order BUILD
Order CKO
Go (proc. orders)
Order PRM
Order PRM RQS
Order CKO RQS
Order BUILD, Go
Order CKO, Go
Order PRM, Go
*/
*/
*/
*/
*/
*/
*/
*/
*/
QAUOOPT
5=Display
ACMSLIB/ACMSPDMCRT
ACMSLIB/ACMSPDMCKO
ACMSLIB/ACMSPDMGO
ACMSLIB/ACMSPDMPRM
ACMSLIB/ACMSPDMPRM
ACMSLIB/ACMSPDMCKO
ACMSLIB/ACMSPDMCRT
ACMSLIB/ACMSPDMCKO
ACMSLIB/ACMSPDMPRM
IDLIB(&L) NAME(
IDLIB(&L) NAME(
IDLIB(&L)
IDLIB(&L)
IDLIB(&L)
IDLIB(&L)
IDLIB(&L)
IDLIB(&L)
NAME(
NAME(
NAME(
NAME(
NAME(
NAME(
More...
Command ===>
F3=Exit
F9=Retrieve
F4=Prompt
F10=Command entry
F5=Refresh
F6=Create
F24=More keys
Figure 63 - IBM Work with User-Defined Options Panel

Note
The figure shows some of the PDM options provided by Aldon. The
complete option list appears in Table 3 on page DO -6.
8. Eliminate any conflicts between your options and those added from
the Aldon file. If two options use the same letter code, whichever
option appears later in the list will not be accessible.
Note
If you added the Aldon supplied options to an existing options file

with CPYF, the Aldon options appear at the end of the list.
If two options use the same letter code, eliminate the conflict by
assigning a new code to either of the conflicting options with the
following steps:
a.
In the Opt field by the option you want to associate with a new
letter code, type 2 (Change) and press ENTER to display the
Change User-Defined Option panel.
b.
At the Change User-Defined Option panel, in the Option field,

type the new letter code.
c.
Press ENTER to confirm the change and return to the Work with
User-Defined Options panel.
9. After resolving all conflicts, press ENTER with no options selected to
save your changes and return to the PDM main menu.

10. At the PDM main menu, press F3 (Exit) to exit PDM.
11. Sign on to Aldon LM(i).
12. Follow the instructions in To define a user options file starting on
page UG 2-7 in the Aldon LM(i) Users Guide to define the user
options file to Aldon LM(i).
Using Aldon Options

Overview and General Instructions
Some Aldon supplied options create action orders in a queue, others
create action orders and execute all queued orders, still others act
immediately on a single object, bypassing the order queue.
Options that process orders from the queue invoke two panels for
selecting orders from the queue for processing. Processing of selected
orders continues using the same panels used in the standard Aldon LM(i)
panel interface. Single-object options streamline the process by omitting
these panels and performing actions either with default values or with
values entered using the F4 option prompt interface.
The Aldon Options

Five options place action orders in a queue without initiating processing:
C, R, B, P, and Q. Five similar options first place an action order in the
queue, and then initiate processing of all queued orders: CG, RG, BG,
PG, and QG. Option G initiates queue processing without creating an
order.
Three options act immediately on a single object bypassing the order
queue and parameter panel interface: C1, B1, and P1. Table 3 provides a
complete list of Aldon LM(i) PDM options.
Table 3 - User Defined PDM Options for Aldon LM(i)
Action Category
Option
Code
Creates an
Order
Request Checkout
RG
CG
Perform Checkout
Processes
Order
Queue
HC
X
X
BG
HB
X
B1
Request Promote
Perform Promote
QG
PG
P1
Process Order Queue
Included in third
party vendor file as
option:
HR
C1
Build (Create)
Performs action on
single object without using orders,
queue, or Aldon
LM(i) panels
X
X
HG
Object Selection
The Aldon LM(i) object database tracks all copies of each release object.
Initiate action on an object by selecting any copy of the object or the
object's source. The option processing program locates the correct copy of
the object to satisfy your request or, when appropriate, allows you to
select the desired copy from the list of available copies.
There are several strategies for selecting objects to act on. List objects or
source members for objects you wish to work with by selecting any
library or source file defined to Aldon LM(i) that contains them. Selecting
the appropriate Production environment library works well for many
purposes because all objects, except those newly added, are present in this
environment. Selecting a library in the environment you wish to act on
limits the display to eligible objects.
Use ASC's Abstract/Probe+ or Hawkeye's Pathfinder to display logically
related groups of objects. Display all programs that use a particular file or
all files used by a particular program. Display all logical files built on a
particular physical file or all physical files used by a particular logical file.
When possible, the option processor determines the release for an object
from the library that contains the option selected copy. When selecting
objects from a developer library, the release is initially ambiguous as a
developer library may contain objects from several releases. To determine
the release for a selected object, the option processor first searches for a
release containing the current library, then searches for the object in the
last release the user worked with using the option interface, then searches
the last release the user worked with using the standard panel interface.
Finally, if the object still is not found, Aldon LM(i) searches all releases
in alphabetical order.
Processing Queued Orders

Select objects with Aldon LM(i) options to create action orders. Select
any number of objects before processing. The order processor breaks up
large groups of orders into batches as necessary.
This section illustrates processing of queued orders using an example in
which three objects are checked out from a PDM object listing of a
release's Production library. Select objects with the C and CG options as
shown in Figure 64. Press Enter to proceed to the Select Orders by
Release panel shown in Figure 65.
Work with Objects Using PDM
Library . . . . .
ACMSDMOPDN

2=Change
3=Copy
8=Display description
Opt
C
C
CG
Object
DEMOCBL1
DEMOCBL2
DEMOCBL3
DEMORPG1
DEMORPG2
DEMORPG3
Type
*PGM
*PGM
*PGM
*PGM
*PGM
*PGM
Position to . . . . . . . .
Position to type . . . . .
4=Delete
9=Save
Attribute
CBL
CBL
CBL
RPG
RPG
RPG
5=Display
10=Restore
__________
__________
7=Rename
11=Move ...
Text
COBOL DEMO Program - 1st Subordinate
COBOL DEMO Program - 2nd Subordinate
RPG Program 1 for Aldon/CMS Demo
Bottom
Parameters or command
===> _________________________________________________________________________
F11=Display names and types
F12=Cancel
F13=Repeat
F14=Display Size
F23=More options
F24=More keys
Figure 64 - IBM Work with Objects Using PDM Panel

PSELORDREL
Select Orders by Release

1=Select
Opt Release
_ ALDON/ACMSDEMO/BASE
<----- Order counts by type -------->

RqsCKO CKO EmgCKO RqsPRM PRM Build
3
Command ===> _________________________________________________________________

F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F14=WRKSBMJOB
F18=WRKSPLF
Figure 65 - Select Orders by Release Panel
One line appears on this panel for each release with orders pending. The
number of orders counts by type appear in columns on the right. Select the
release with option 1 and press Enter to proceed to the Select Orders
panel. If the queue contains orders for only one release the Select Orders
panel is the first panel displayed.
All orders pending for a given release display on the Select Orders panel
as shown in Figure 66. The Select Orders panel appears once for each
release selected on the Select Orders by Release panel.
PSELORD
Release:
Select Orders
ALDON/SITE/CORPORATE

1=Process
4=Delete
Opt
1
Description
Orders
Request Checkout
Check out
3
Check out - emergency
Request Promote
Promote
Build (Create)
Errors
Command ===> __________________________________________________________________

_______________________________________________________________________________
F3=Exit
F4=Prompt
F9=Retrieve
F12=Cancel
F14=WRKSBMJOB
F18=WRKSPLF
Figure 66 - Select Orders Panel
Select the categories of orders you wish to process with option 1 and press
Enter to proceed to the standard confirmation panels for each type of
order. In this example, select Check out with option 1 to process all
checkout orders for this release using the panels discussed in the section
Checking Out Objects, starting on page DO 3-2. For this example, the
Check Out Objects panel shown in Figure 67 on page DO D-10 appears.
Processing a category on the Select Orders panel with option 1 processes
the valid orders and deletes those with errors for that category. Use option
4 to delete all orders pending for the release in a particular category.
If the release specification is invalid, the Select Orders panel displays with
only option 4=Delete active and a Status message describing the problem
appears immediately below the release identification line. Delete all
pending orders for the invalid release, correct the problem, and submit the
orders again.
CCKOOBJ
Release:
Check Out Objects

ALDON/ACMSDEMO/BASE
Type the additional checkout information below, press Enter.

To developer . . . . . .
For task . . . . . . . .
Emergency checkout? . . .
Remove active checked out
Print checkout report? .
Run option . . . . . . .
. . . .
. . . .
. . . .
object?
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
MARKE
N
N
N
1
+ Name
+ Name
Y=Yes, N=No
Y=Yes, N=No
Y=Yes, N=No
2=Run in batch

Objects selected for checkout
Object
DEMOCBL1
DEMOCBL2
DEMOCBL3
F3=Cancel
Type
*PGM
*PGM
*PGM
F4=Prompt
Attribute
CBL
CBL
CBL
More: - +
---Env
QUA
ITG
PRD
F7=Add task
From ----Library
ACQUAL
ACINTG
ACMSDMOPDN
F12=Cancel
F20=Enlarge list
Figure 67 - Check Out Objects Panel
After selecting the release and category of orders for processing,

accomplish the remainder of ordered actions using panels in the standard
Aldon LM(i) interface. The connection between the PDM or third party
vendor program's object or member list and the standard Aldon LM(i)
interface panels is seamless. All Aldon panels are fully supported with
cursor sensitive help text.
Using Single-Object Options

Check out, build, or promote a single object quickly using default values
with the single-object options C1, B1, and P1. Single-object options
execute immediately when you press Enter using default values for all
parameters. Panels for managing the order queue and specifying
parameters do not display. For information on default values see syntax
diagrams for the ACMSCHKOUT, ACMSCREATE, and
ACMSPROMOT commands, or prompt these commands or the
single-object options with F4.
For example, select an object for checkout with C1 and press Enter.
Aldon LM(i) performs a standard checkout with the current user as
developer under the assigned task if the object is in a task, and does not
automatically replace an existing copy in the target developer library or
produce a checkout report.
Use single-object options to quickly process a single object. Each

single-object option runs as a separate job and without recognition of
possible object interdependencies with other selected objects.
User Supplied Options

Aldon LM(i) supports user supplied options on the Work with... panels
accessed through the first five main menu options: Work with Objects by
Developer, Work with Object by Release, Work with Archive Objects,
Work with Requests and Non-Conflict Conditions, and Work with Tasks
panels.
Creating User Options

Create user options using the PDM option editor by selecting option 9 on
the initial PDM menu and then pressing F6, or by using a file editor.
Select a two character option designator not already in use. Enter the
command to perform the option action and any parameters you wish to fill
with data from the Aldon LM(i) panel. Use substitution variables shown
in Table 4. Command parameters not available from a given Aldon LM(i)
panel via substitution may be entered during use of the option by
prompting with F4.
The following example displays the System i description of an object
from the Work with Objects by Developer panel:
DO DSPOBJD OBJ(&L/&N) OBJTYPE(&T)
An option using these substitution variables may also be used on other

Aldon LM(i) panels if prompted for the name of the library containing the
object. The substitution variable &L is not available on other panels as
object entries may represent copies of the object in multiple environment.
Table 4 - Substitution Variables Supported

Var
Meaning
From the Work with Objects by Developer Panel:

&N
Object name
&T
Object type
&A
Object attribute
&L
Object library
&SM
Object source member
&F
Object source file
&SL
Object source library
&GP
Group name
&PD
Product name
&RS
Release selected
&RF
Release in which object exists
&EV
Environment.
&SE
Subenvironment (developer)
&X
Object description (from Aldon LM(i) database)
&US
Logon user name
&C
User defined option.
From the Work with Object by Release Panel
&N
Object name
&T
Object type
&A
Object attribute
&SM
&F
Object source file
&GP
Group name
&PD
Product name
&RS
Release selected
&RF
&X
&US
Logon user name
&C
Table 4 - Substitution Variables Supported (Continued)

Var
Meaning
From the Work with Tasks Panel

&N
Task name
&GP
Group name
&PD
Product name
&RS
Release selected
&RF
Release in which task exists
&X
Task text
&US
Logon user name
&C
From the Work with Archived Objects Panel

&N
Object name
&T
Object type
&A
Object attribute
&SM
&F
Object source file
&GP
Group name
&PD
Product name
&RS
Release selected
&RF
&X
&US
Logon user name
&C
Table 4 - Substitution Variables Supported (Continued)

Var
Meaning
From the Work with Conditions Panel
&N
Object name
&T
Object type
&A
Object attribute
&GP
Group name
&PD
Product name
&RS
Release selected
&RF
&EV
Environment.
&SE
Subenvironment (developer)
&US
Logon user name
&C
Defining the Options File to Aldon LM(i)

To define the user options file
1. At the Aldon LM(i) main menu, press F22 (More functions) to
display the More Functions panel.

2. At the More Functions panel, in the option field, type 2 (Set user
defined option file) and press ENTER to display the Set User Options
panel:
CUSROPT
Set User-Defined Option File

File . . . . . . . . .
Library . . . . . .
Member . . . . . . . .
*NONE
*NONE
*NONE
*NONE, name
Name
*FIRST, name
Command ===>
F3=Exit
F4=Prompt
F5=Refresh
F9=Retrieve
F12=Cancel
Figure 68 - Set User-Defined Option File Panel

3. Specify the file, library, and member containing the user options in
the fields provided and press ENTER.
Using User Options in Aldon LM(i)

Enter the character code for the desired user option by the item upon
which you wish to act and press either Enter to execute immediately or F4
to prompt the command for completion of additional parameters.

Daily Operations
DO
Appendix E
Interface to Abstract/Probe+ and
Pathfinder
Aldon Lifecycle Manager for System i (Aldon LM(i)) provides several

interface features for shops using Abstract/Probe+ from Advanced Systems
Concepts (ASC) or Hawkeye's Pathfinder for documentation and cross
referencing.
Quick access to both packages is provided via F22=More functions which
is available on many Aldon LM(i) panels. This enables inquiries without
leaving Aldon LM(i).
Perform Aldon LM(i) functions directly from Abstract/Probe+ or Pathfinder
via user-defined options. Both ASC and Hawkeye include a file containing
Aldon LM(i) PDM-Style User Options with their products, allowing initiation
of Aldon LM(i) functions directly from Abstract/Probe+ or Pathfinder panels.
See PDM-Style User Options, starting on page DO D-1 for further
information on the use of Aldon provided PDM options.
Configure Aldon LM(i) to access your vendor program using the Describe
Third Party Vendor Products panel accessed with option 11 from the Global
Setup menu. Use the Define Documentation by Third Party Vendor Product
panel accessed with option 9 from the Global Setup menu to configure
automatic updating of your documentation tool's cross-reference database
each time a program is promoted to an Aldon LM(i) Production library.
Interface to Abstract/Probe+ and Pathfinder DO E-1
DO E-2 Interface to Abstract/Probe+ and Pathfinder

Daily Operations
DO
Appendix F
The Panel Interface
Introduction
Aldon products follow the SAA/CUA (System Application
Architecture/Common User Access) Standards defined for the System i by
IBM. These standards are gradually coming into widespread use. Some
features of the standards included in Aldon products are not yet included in
IBM's most frequently used System i panels.
The Users Guide section Summary of Panel Interface Features, starting
on page UG 4-2 provides information on the following topics:
Context-Sensitive Help Text on page UG 4-2
Input Fields: Prompting and Selecting on page UG 4-33
Scrolling on page UG 4-3
Fully Functional Command Line on page UG 4-4
This appendix describes additional user interface features not covered by the
Users Guide and provides additional details regarding some features.
The Panel Interface DO F-1
The System i Panels

Line
Number
STRALDPRD
Start ALDON Products
1
2
Common installation library . . . :
ALDONCOMM
Type options, then Press enter.
1=Select
5=Display installation data
Opt
19
20
21
22
23
24
25
Product
ACMS
ANALYZER
INTEGRATE
HARMONIZER
S/COMPARE
Text
Aldon
Aldon
Aldon
Aldon
Aldon
Change Management System

Analyzer (Test Coverage Monitor)
Automated Integration Tools
S/Compare and Harmonizer
S/Compare without Harmonizer
Status
Not found
Not found
Installed
Installed
Not found
Command ===>
F3=Exit
F4=Prompt
F14=WRKSBMJOB
09-03
SA
F9=Retrieve
F10=Show library
F11=Show version
F18=WRKSPLF
MW
KS
IM
II S1 ALDONT01 KB
Figure 69 - Sample Aldon Product Panel
The parts of a typical Aldon panel and their locations on the sample panel
shown in Figure 69 are as follows:
Table 5 - Parts of a Typical Aldon Panel
DO F-2 The Panel Interface
Location
Description
line 1
Panel Name and Title
lines 2-19
The panel body. Contains input capable fields, display

fields, selection menus, instructions, etc.
line 20
A program message line is located immediately below

the working area of the panel. This line remains blank
when there is no message to display. If there is more
than one message, a + appears at the right end of the
message line. Press Page Down (Roll Up) to view the
additional messages. Press F4 to view the detailed version of a message.
line 21-22
A command line is present on most panels immediately below the message line.
line 23-24
Function key prompts are displayed at the bottom of

the panel.
line 25
Terminal information line.
Panel Name and Title

Every Aldon Lifecycle Manager for System i (Aldon LM(i)) panel has a
name in upper left corner followed by a title. The user documentation
usually refers to panels using the full title.
Panel Body
The area of a panel between the program message line and the title line
receives input from and displays information to the user.
Input Fields
Input fields appear as underscores. (See the section PC Terminal
Emulation for exceptions.) Accepted values are often listed to the right of
the field. If a + symbol appears after the field, you may prompt for a list
of accepted values by placing the cursor in the field and pressing F4. The
list of values is displayed on a single selection panel or multi selection
panel. Selection panels are described below.
A description of the field and the range of accepted values is always
available through help text. In some cases default values may be entered
for you. If there is an underscore, you may change the value. Values
preceded by a colon (:) are display only and cannot be changed.
More: -+
When there is more information to view than will fit on one panel, More:
+, More: -+, or More: - displays on the right side of the panel
(Figure 73, Figure 74, and Figure 75). Press Page Down (Roll Up) when
+ displays, or Page Up (Roll Down) when - displays to view
additional items.
Line
Number
CWRKOBJ
Example Panel: Work with Objects
3 Application:
Text . . . :
4
Object . . .
5
Condition
6
7
ALDON/DEMOAPP
Release . . . : RELEASE11
Release 1.1 of Demonstration Application
*ALL
Type . . . . . .
*ALL
+
*ALL +
Environments . .
*ALL +
Position to . .
Type options, the press Enter.
3=Check out*
4=Delete
7=Promote*
13=Request checkout
17=Request promote ...
(*=Combined job)
More: - +
Opt
__
__
__
__
__
__
__
__
Object
DEMOCL1
DEMOCL2
DEMOCL3
DEMOCL4
DEMOCL5
DEMOCL6
DEMORPG1
DEMORPG2
Type
*PGM
*PGM
*PGM
*PGM
*PGM
*PGM
*PGM
*PGM
Attribute
CLP
CLP
CLP
CLP
CLP
CLP
RPG
RPG
Cnd
R
R
C
Env
IP
IP
P
QP
QP
QP
DP
DP
DVPs
2
1
Emg
N
N
N
N
N
N
N
Y
Command ===> _________________________________________________________________

F3=Exit
F5=Refresh
F6=Add Object
F8=Check out F10=Promote
F12=Cancel
F24=More keys
Figure 70 - Example Panel: Work with Release Objects Panel
Selection fields
Some panels which display lists of items provide selection fields (lines 5
and 6, Figure 70 on page DO F-4) for limiting the items displayed. The
selection fields default to values which display the largest number of
items. Change one or more selection field to tailor the group displayed to
your requirements. Press the Enter key to display the selected items. Only
items which satisfy all or the selection criteria display. Change the
selection fields and press Enter again to display different items. Panels
entered from a panel with subsetting by selection fields in effect use the
same selection criteria.
Position to
A panel which displays long lists of items may have a Position to field
(line 7, Figure 70 on page DO F-4) to aid in finding desired items. Enter
an item name or search string and press Enter. The list of items is scrolled
so that the first item matching appears on the top line. If no item matches
exactly, the item in the list immediately preceding the name's position is
displayed.
CSBSOBJ
Example Panel: Subset Objects List

Object
. . . . . . . .
*ALL
*ALL
Has condition . . . . .
*NA
*NA, *ANY, *NOT, A/C/R
In environment
*NA
*NA, *ACT, D/I/Q/P
F3=Exit
. . . .
F4=Prompt

+
F5=Refresh
*ALL, type
F12=Cancel
Figure 71 - Example Panel: Subset Objects List
Subsetting
Sometimes selection fields appear on a separate Subset panel, such as
the one shown in Figure 71, obtained by pressing a function key (usually
F17).
WRKOBJ
Application:
ALDON/DEMOAPP
Release
. . . :
RELEASE11

2=Edit source
4=Delete
5=Browse source
6=Print attributes
14=Create*
15=Change create options ...
(*=Combined job)
More: - +
Opt Object
Type
Attribute Cnd Env DVPs Emg
__ DEMOCL1
*PGM
CLP
IP
N
__ DEMOCL2
*PGM
CLP
R
IP
N
__ DEMOCL3
*PGM
CLP
P
N
__ DEMOCL4
*PGM
CLP
QP
N
__ DEMOCL5
*PGM
CLP
QP
N
__ DEMOCL6
*PGM
CLP
R
QP
N
__ DEMORPG1
*PGM
RPG
C
DP
2
N
__ DEMORPG2
*PGM
RPG
DP
1
Y
__ DEMORPG3
*PGM
RPG
C
DP
2
N
__ DEMORPG4
*PGM
RPG
DP
1
Y
__ DEMORPG5
*PGM
RPG
DP
1
N
__ DEMORPG6
*PGM
RPG
DP
1
Y
Command ===> _________________________________________________________________
F3=Exit
F5=Refresh
F6=Add Object
F9=Retrieve
F12=Cancel
F20=Reduce list
F23=More options
F24=More keys
Figure 72 - Example Panel: Work with Objects
Enlarge/Reduce List
In other cases, Aldon provides a function key to hide fields at the top of a
panel to make more space available for list entries. This feature is usually
activated with F20. When available, press F20 to hide fields at the top of
the panel and enlarge the item list to fill the available space. Press F20
again to reduce the list and restore the hidden fields. Figure 72 shows the
example Work with Object panel as it might look after use of an Enlarge
list function key.
Additional Option Prompts

When more options are active for a panel than fit in the option prompt
area, an ellipsis (...) appears after the last prompt. Press F23=More
options to display additional options in the prompt area. Options are
active regardless of whether or not they are currently displayed in the
prompt area.
Additional Function Key Prompts
When more function keys are active for a panel than fit on the function
key prompt area at the bottom of the panel, press F24=More functions to
toggle the display to show additional function key choices. Function keys
remain active regardless of whether or not they appear in the prompt area.
Alternate Views
On some panels which display columns of information, you may obtain
additional columns of information by pressing Function keys identified
with the prompts View 2, View 3" etc. at the bottom of the panel. Each
time an alternate view is displayed by pressing a function key, the labels
and actions of the function keys rotate so that the previous view may be
recalled.
Multi-Page Panels
In cases where it is necessary to set a larger number of related options
than will fit on a single display screen, the Page Up and Page Down keys
(Roll Down and Roll Up) are used to move between the related panels.
More: + is displayed on the first panel (Figure 73) to indicate that more
options must be viewed by pressing Page Down. After completing the
options on the first panel, press the Page Down key to display additional
options (Figure 74, Figure 75).
CGLBDOPT1
Define Global Options

Global options:
Activate user request facility . . . . .
Copy text to task notes category . . .
Y
*NONE
Allow long object names . . . . . . . .

Default TGTRLS for create commands . . .
Defaults for new applications:
Default owner of objects . . . .
Use activity log . . . . . . . .
Use deployment log . . . . . . .
Default source file text length
Use archiving . . . . . . . . .
Maximum copies to archive . .
Archive source only . . . . .
Compress source . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Y
V5R2M0
.
.
*NONE
Y
Y
.
.
.
.
.
100
Y
3
Y
N
More: - +
Allow Override
(Y/N)
Y=Yes, N=No
*NONE,
notes category
Y=Yes, N=No
*NONE, *PRV,
Y
*CURRENT, VxRxMx
*NONE, name
Y
Y=Yes, N=No
Y
Y=Yes, N=No
Y
1-32754
Y
Y=Yes, N=No
Y
1-998, *NOMAX
Y
Y=Yes, N=No
Y
Y=Yes, N=No
Y
Command ===> _________________________________________________________________

F3=Exit
F4=Prompt
F5=Refresh
F9=Retrieve
F12=Cancel
Figure 73 - Sample Multi-Page Panel, 1 of 3
CGLBDOPT2
More: - +
Allow Override
(Y/N)
Defaults for new releases:

Require comment to promote . . .
Allow multiple check outs. . . .
Require request to check out . .
Require comment to check out . .
Require task to check out . . .
Library group assignment . . . .
If exit program, library . . .
Allow promotes with conflicts to
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
N
Y
N
N
N
*MAP
Maintain object dependency data . . . .

SQL naming option . . . . . . . . . . .
Try available update for object replace
Y
*SYS
N
*NONE
Y=Yes, N=No
Y=Yes, N=No
Y=Yes, N=No
Y=Yes, N=No
Y=Yes, N=No
*MAP, *PROMPT,
exit program
*NONE, ITG,
QUA, PDN
Y=Yes, N=No
*SYS, *SQL
Y=Yes, N=No
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Command ===> _________________________________________________________________

F3=Exit
F4=Prompt
F5=Refresh
F9=Retrieve
F12=Cancel

CGLBDOPT3

Defaults for new releases (continued):
Production environment options:
Require request to promote to . . .
Create objects when promoting to . .
Run S/Compare when promoting to . .
Require request to install live from
Reference library . . . . . . . . .
More: Allow Override

(Y/N)
.
.
.
.
Allow promotes to parent release . . .
N
Y
N
N
*NONE
N
Y=Yes,
Y=Yes,
Y=Yes,
Y=Yes,
*NONE,
name
Y=Yes,
N=No
N=No
N=No
N=No
*LIBL,
Y
Y
Y
Y
Y
N=No
Command ===> _________________________________________________________________

F3=Exit
F4=Prompt
F5=Refresh
F9=Retrieve
F12=Cancel
Use Page Up and Page Down to view and change options until the desired
settings are achieved, then press Enter to submit the panels. Values are not
accepted for processing until all available panels are viewed.
Function Keys
At the bottom of each panel are one or more lines of function key
prompts. If there is not enough room to display prompts for all of the
active function keys, the most commonly used keys are displayed by
default. Press function key F24 to retrieve the remaining prompts. A
function key defined for a panel remains active even when its prompt is
not displayed. Some function keys perform consistent actions on all
panels. Others work in one of several ways depending on the panel.
Below is a list of the most common function keys and descriptions of their
modes of action. Check the help text to be sure of a key's affect on a given
panel.
Table 6 - Common Function Keys

Function Key
Description
Help Key or F1=Help Text
Retrieves help text keyed to the position of the cursor.
F3=Exit
Exit the current function and return to the panel from which it was called. Most
functions in Aldon LM(i) are contained in a single panel. In these cases, F3 and F12
which cancels the current panel will appear identical in function.
F4=Prompt
Place the cursor in a field followed by a + symbol and press F4 to prompt for a list
of input values. Press F4 with the cursor on the command line, or anywhere else, to
prompt for System i commands.
F5=Refresh
Refresh fields with current values. Current values of input capable fields are not
updated until the Enter key is pressed. If the panel was initially displayed with
default values, these default values are restored. If the panel displays values which
change as a job executes, the values present in the system when the function key is
pressed are displayed.
F6, F7=Add...
Used for adding a variety of user defined items to the system.
F9=Retrieve
Retrieves System i commands entered on the command line during the current
Aldon session. Commands are retrieved in last-in first-out order. After retrieving
commands back to the beginning of the queue, a blank line is displayed, then
retrieval starts over again with the most recent command.
F11=View 1,2,3
Display additional information about each item listed.
F12=Cancel
Exits from the current panel to the previously displayed panel without performing
the action in progress.
F13=Repeat
Repeat any valid option from a particular item downwards to the end of the list in an
option field. Options selected for preceding items in the list, above of the current
cursor position, are left alone.
F14=WRKSBMJOB
Executes standard IBM work with submitted jobs command.
F15=Full name
and
F15=Full name/fold,
F15=Unfold
If the cursor is positioned on an object name, displays the full object name. If a caret
(>) appears to the right of the object name, less than the full name is being displayed
on the panel.
On Work with... panels with record including object names, if the cursor is outside
the record list area, toggle between folded and unfolded record display mode
which truncates or displays long object names using two-line records.
F17=Subset
Display a panel with several selection fields. Enter values in the fields to limit items
selected for display on the previous panel.
F18=WRKSPLF
Executes standard IBM work with spool files command.
F20=Enlarge/Reduce list
Hide fields at the top of a list panel to make room for more list entries. Reduce the
list and restore the hidden fields by pressing the key again.
F23=More options
Toggle the option prompt lines to display additional options which are available.
F24=More keys
Toggle the function key prompt lines to display additional function keys which are
available.
Enter Key
The Enter key submits the panel for processing. If a command has been
keyed on the command line, only the command is processed. Values
keyed elsewhere on the panel are saved but not processed while the
command is executed. When the command has executed the panel is
redisplayed with the keyed values and a blank command line. Press Enter
again to process the values keyed on the panel, or enter another command
on the command line.
If no command has been entered, the values keyed in the panel body are
edited by the terminal program for adherence to input requirements. If all
values keyed meet input requirements, the data is processed. The same
panel or next panel is displayed as requested.
Program Message Line

The program message line remains blank most of the time, and serves as a
boundary between the body of the panel and the command line and
function key prompts below. Informational messages about system status,
reminders about input requirements, error messages, and messages
regarding batch job execution are displayed here. A + symbol at the end
of a message indicates that the message is longer than one line, or that
there are additional messages to display. Position the cursor on the
message line and press the Page Down key to view additional message
lines. To view a more detailed version of a message, position the cursor on
the message line and press the Help key.
Terminal Message Line

Terminals perform some basic input validation before transmitting key
strokes to the host system. Input error messages generated by the terminal
are displayed on the last line of the panel.
Selection Panels
When F4 is pressed with the cursor on and input field followed by a +
symbol, a selection panel listing available values for the field is displayed.
There are two types of selection panels: single item and multiple item.
Single Selection Panels

Only one item may be chosen from a single selection panel. Type a /
(any character except .) over the period preceding the item you wish to
select and press Enter. The selected item is entered in the input field on
the preceding panel.
CSELGRP
Example Panel: Single Selection
Select one group by typing a / over the period, then press Enter.
Group
. ALDON
. BILLR
. BONNIEM
F12=Cancel
Figure 76 - Example Panel: Single Selection
Multiple Selection Panels

When prompting to complete a series of identical input fields, values
display on a multiple selection panel such as the panel shown in Figure 77
on page DO F-10. Select as many items as desired on a multiple selection
panel. Type a 1 in the field preceding each item you wish to select and
press Enter. The selected items are entered in the input fields on the
preceding panel.
CSELRLO
Select Objects
Release . . . . . . . . :
Subset object type . . . .
Position to . . . . . . .
MARKE/MARK1/BASE
*ALL
+ *ALL, type

1=Select
Opt Name
CLNADR
1 CLNADRL
1 DEMOCBL1
DEMOCBL2
1 DEMOCBL3
KEYEDPF
Type
*FILE
*FILE
*PGM
*PGM
*PGM
*FILE
F12=Cancel
Figure 77 - Example Panel: Multiple Selection
Option Processing for Sub-Files (Lists)

Some panels in Aldon products display a list or sub-file of items each of
which may be manipulated by entering a menu selection on the option
line immediately preceding it to the left and pressing Enter.
There are two types of options: standard options and combined job
options. An asterisk (*) following the option prompt indicates a combined
job option. All other options are standard options.
Select any number of items for action with a given combined job option
but do not mix requests for a combined job option with any other options.
Combined job options perform operations on items which may be
interdependent in the order required by their relationships.
Select any number if items for action with any combination of standard
options. Aldon LM(i) processes items selected with standard options in
order from the top of the list to the bottom. For some combinations of
options, adherence to this processing order is obvious. However, some
options pool all items selected for that action for parameter entry and
confirmation on one panel. This gives the appearance that all items
selected for the option are processed together at that time, but list order
processing is preserved.
Processing of these options is handled as follows. The parameter entry or
confirmation panel displays when the first item selected with the option is
encountered in the list. The program searches the remaining list for other
items flagged for that option and displays all on this panel. Press Enter
from this parameter entry or confirmation panel to process the first item
selected and save parameters and the confirmed=Yes flag for the
remaining items. Processing continues with the next item in the main list.
As each item selected for the confirmed option is encountered, it is
processed without display of a panel or other visible cue using the
previously entered parameters and confirmation flag. Cancel processing
of the list at any time with F12 or F3. This clears saved parameters and
confirmed flags for un-executed selections and redisplays the main list
showing those options that remain unprocessed.
WRKOBJ
Application:
ALDON/DEMOAPP
Release
. . . :
RELEASE11

2=Edit source
3=Copy
4=Delete
5=Browse source
14=Create*
15=Change create options ...
(*=Combined job)
More: - +
Opt Object
Type
Attribute Cnd Env DVPs Emg
2 DEMOCL1
*PGM
CLP
IP
4 DEMOCL2
*PGM
CLP
IP
8 DEMOCL3
*PGM
CLP
P
4 DEMOCL4
*PGM
CLP
QP
DEMOCL5
*PGM
CLP
QP
8 DEMOCL6
*PGM
CLP
QP
DEMORPG1
*PGM
RPG
DP
DEMORPG2
*PGM
RPG
DP
DEMORPG3
*PGM
RPG
DP
DEMORPG4
*PGM
RPG
DP
DEMORPG5
*PGM
RPG
DP
Command ===> _________________________________________________________________
F3=Exit
F5=Refresh
F6=Add Object
F9=Retrieve
F12=Cancel
F20=Reduce list
F23=More options
F24=More keys
Figure 78 - Example Panel: Work with Objects
The following table describes the step-by-step processing of the options

selected in the example panel above.
Table 7 - Sub-File Option Processing Example
Option and Object
Discussion
2 DEMOCL1
Processing begins at the top of the list. The SEU

source member editing panel displays. Edit source.
Exit SEU when finished to continue option processing.
SEU Panel for editing

DEMOCL1
Processing continues with the second selected object.

A confirmation panel displays for all objects selected
for deletion. Press Enter to confirm deletion of all
objects selected and delete DEMOCL2.
Delete Confirmation
4 DEMOCL2
Display
Proceed with Delete?

DEMOCL2
DEMOCL4
Table 7 - Sub-File Option Processing Example

8 DEMOCL3
The Display attributes option does not pool all

selected objects for processing. There are no parameters to enter and there is no need for confirmation.
Each object selected is processed individually as it
appears in the list.
4 DEMOCL4
The confirmation flag for deletion of this object was

obtained when the first deletion was encountered.
DEMOCL4 is now deleted without display of a
panel.
8 DEMOCL6
The final object is processed.
Object Attributes Display

for DEMOCL3
xxxxxxx xxxxx xxxxx
xxxxx xx xxxxxx xxxxxx
(DEMOCL4 deleted at
this point with no display)
Object Attributes Display

for DEMOCL6
xxxxxxx xxxxx xxxxx
xxxxx xx xxxxxx xxxxxx
This table refers to the example depicted on the panel shown in Figure 78
on page DO F-12.
PC Terminal Emulation
Some older IBM System i terminal emulation software for PCs does not
support underscored alphanumeric characters. Consequently, input
capable fields are sometimes not obvious to users working from PC's.
When a value does not completely fill an input field, the empty positions
display as underscores and the field is recognizable as input capable. For
example, the Type field on line 5 in Figure 70 on page DO F-4 would
appear as *ALL___ on a PC instead of *ALL. In cases where the value
completely fills the field, no underscore characters are present, and the
field may be mistaken for a display field. When in doubt, try entering a
value or use Help text.

Daily Operations
DO
Appendix G
SQL Objects
This appendix includes the following topics:

Adding SQL Objects, starting on page DO G-2
SQL Packages, starting on page DO G-3
Object Text for SQL Objects, starting on page DO G-4
Online Help Text
help text.
SQL Objects DO G-1
Adding SQL Objects

Add SQL objects using the procedures described in Adding an Object
starting on page UG 5-2 in the Aldon LM(i) Users Guide. Additional
information specific to SQL objects is provided below.
The following table provides information for adding SQL objects
supported by Aldon LM(i):
SQL Object
Related System i System

Type
Aldon LM(i) Type
Alias
*FILE
*ALIAS
Index
*FILE
*INDEX
Table
*FILE
*TABLE
View
*FILE
*VIEW
Package
ILE: *PGM, *MODULE, or

*SRVPGM
*SQLPKG
Function
*PGM or *SRVPGM
*FUNCTN
Aldon LM(i)
Extended Attribute
EXT
SQL
SRC
Procedure
*PGM or *SRVPGM
*PROC
EXT
SQL
Trigger
*PGM or *SRVPGM
*TRIGGER
Type
*SQLUDT
*TYPE
All types can be defined as non-source or pseudo source base.

Creating Pseudo-Source for SQL
See Working with Pseudo-Source starting on page UG 5-6 in the
Aldon LM(i) Users Guide for more information.
Details for Adding SQL File Based Objects
When adding SQL file based objects, a second panel appears for
specification of the System i system name of the underlying file object on
which the SQL object is based.
Details for Adding SQL Package Objects
See SQL Packages, starting on page DO G-3.
DO G-2 SQL Objects
Details for Adding Functions and Procedures

When adding SQL functions and procedures in Aldon LM(i), the name
you specify on the Add Object panel is the SPECIFIC parameter for the
object creation statement. You must designate pseudo-source as the
source option. Specify the SQL procedure or function name for the
function or procedure on a subsequent panel that displays automatically
when needed.
Details for SQL Trigger and User Defined Type Objects
When adding SQL trigger and type objects, you must designate
pseudo-source as the source option. No additional panels display during
the add process.
Note
In the present release you can define SQL user defined types present in
Production libraries to Aldon LM(i) but they cannot be checked out,
promoted, or deployed.
SQL Packages
Aldon LM(i) handles SQL packages, (object type *SQLPKG). An SQL
package allows faster execution of SQL statements in an ILE program,
module, or service program by storing SQL statements from the program
prepared in advance of program execution.
Most Aldon LM(i) functions and features work with SQL packages. You
can load and map SQL packages using standard loading and mapping
procedures. You can checkout, create, and promote SQL packages using
standard Aldon LM(i) options and procedures. When you copy releases,
Aldon LM(i) handles SQL packages. You can include SQL packages in
tasks and deploy SQL packages.
SQL packages are not archived.
SQL packages are non-source
objects
Outside of Aldon LM(i), you create SQL packages using the OS/400 CL
command CRTSQLPKG. This command examines the ILE program you
designate and prepares and stores as many of the SQL statements it
contains as possible. SQL packages are therefore not source based or
pseudo-source based, but rather, are defined to Aldon LM(i) as
non-source objects.
SQL Objects DO G-3
Phantom programs created to

support SQL packages
Each SQL package is associated with one copy of an ILE program.

Therefore, if you checkout an SQL package without also checking out the
corresponding ILE program, Aldon LM(i) creates a phantom copy of
the ILE program in the Developer environment for the SQL package to
reference. As you promote the SQL package, Aldon LM(i) creates and
deletes phantom copies of the ILE program as necessary to ensure that the
copy of the ILE program the SQL package references is in the same
environment.
A promote requirement
When you add and promote a new SQL package, the ILE program with
which the package is associated must be resident in the promote to
environment or a higher environment (closer to Production). This allows
Aldon LM(i) to make sure that a copy, either resident or phantom, of the
ILE program is present in the promote to environment so the SQL
package can be recreated there. If the SQL package and the ILE program
on which it is based are both resident in the same environment, you can
promote them together to satisfy this requirement.
To add an SQL package

You can create an SQL package for ILE program objects of type *PGM
and *SRVPGM. The program object must have an extended attribute of
ILE or BND.
Add an SQL package to Aldon LM(i) using the general instructions
provided in To add an object on page UG 5-3 in the Aldon LM(i)
Users Guide. Use the object type *SQLPKG and source option 9 (No
source).
Notes
You must create a new SQL package manually the first time in
Development using the CRTSQLPKG command so that Aldon LM(i) can
scan and capture parameters required to recreated it as needed later. The
SQL program the SQL package supports must exist in the Development
library when you add the SQL package.
Object Text for SQL Objects

When you add or create a non-SQL object with Aldon LM(i), text for the
object is retrieved and made available for viewing on Aldon LM(i) panels.
To the extent possible, Aldon LM(i) also performs this service for SQL
objects.
For SQL objects, Aldon LM(i) first tries to retrieve the
LONG_COMMENT from a COMMENT ON statement for the object. If
a LONG_COMMENT is retrieved, Aldon LM(i) captures and displays
the first 50 characters of the maximum allowed length of 2000 bytes.
DO G-4 SQL Objects
This LONG_COMMENT method does not currently work for *TYPE

and *TRIGGER objects.
If no LONG_COMMENT is retrieved, Aldon LM(i) attempts to retrieve
the TEXT value for the corresponding system object. (Note: this is not
possible for *PROC and *FUNCTN objects.)
SQL Performance Improvement Suggestions

Having large numbers of files on your system can affect performance in
reading system files. Creating the following indexes can improve
performance significantly. The commands should be entered using the
SQL interface (STRSQL or RUNSQLSTM using an SQL source member
that contains the commands).
CREATE INDEX USRSYS/DBXREL_DBXFIL_DBXLIB_DBXATR ON
QSYS/QADBXREF (DBXREL, DBXFIL, DBXLIB, DBXATR)
CREATE INDEX USRSYS/DBXREL_DBXAFL_DBXALB_DBXATR ON
QSYS/QADBXREF (DBXREL, DBXAFL, DBXALB, DBXATR)
CREATE INDEX USRSYS/DBXREL_DBXLFI_DBXLB2_DBXATR ON
QSYS/QADBXREF (DBXREL, DBXLFI, DBXLB2, DBXATR)
CREATE INDEX USRSYS/DBXFIL_DBXATR ON QSYS/QADBXREF
(DBXFIL, DBXATR)
CREATE INDEX USRSYS/DBFFDP_DBFLIB ON QSYS/QADBFDEP
(DBFFDP, DBFLIB)
SQL Objects DO G-5
DO G-6 SQL Objects

Daily Operations
DO
Daily Operations Reference Index

Page Identifiers in Aldon System i Documents
Page identifiers consist of a two character
document abbreviation followed by a chapter
number or appendix letter, and a page number
within that chapter or appendix.
Example: DO 1-5 indicates the fifth page of
chapter 1 in the Aldon LM(i) Daily Operations
Reference Reference.
Using This Single-Document Index
1. Locate the desired topic in the index.
2.
Click on a page reference to jump to the

indicated page.
3.
From a referenced page, you can right-click,

then select Go Back from the pop-up menu
one or more times to return to this index.
For assistance in using Acrobat, see the chapter

Using CD-ROM Documents Online in the
Installation Guide.
Symbols
*ALIAS, custom object type, see SQL, aliases
*BNDDIR, see binding directory
*CMD objects
creating in Development DO 4-7
identifying command processing program DO 4-7
*CONTAIN files
controlling replication of DO C-9, DO C-10
defined DO C-3
limitations and requirements DO C-3
mapping or loading files for DO C-5
overview DO C-2
replication of, controlling DO C-10
*FUNCTN, custom object type, see SQL, functions
*INDEX, custom object type, see SQL, indexes
*MENU objects
adding DO B-3
adding using pseudo-source DO B-8

working with DO B-6
working with pseudo-source based DO B-12
*PROC, custom object type, see SQL, procedures
*RCDS objects DO C-2
adding DO C-5
and multiple-release applications DO C-12
defining DO C-5
promoting, first time DO C-11
*SQLPKG, custom SQL object type, see SQL, packages
*SQLUDT (System i object type), see SQL, types, user
defined
*SRVPGM (System i object type), see service programs
*TABLE, custom object type, see SQL, tables
*TRIGGER, custom object type, see SQL, triggers
*TYPE, custom object type, see SQL, types, user
defined
*VIEW, custom object type, see SQL, views
A
Abstract/Probe+
access DO 2-4
acknowledgements
analyzer cleared DO 5-6
acknowledgment conditions
emergency checkout/promote DO 5-6
ACMSCHKFRN command
adding objects to release from vendor release DO
4-13
ACMSCHKFRN command (check out foreign object)
mentioned DO 4-13
Act upon Dependent Objects panel DO 4-28
activate conflict DO 5-10
Add Binding Directory Entry panel DO 4-23
add conflict DO 5-9
Add Release Object panel DO C-6
Aldon LM(i)
design strategy DO viii
users DO 1-14
Aldon LM(i) main menu DO 2-2
Aldon option setup
for Abstract/Probe+ and Pathfinder DO D-2
PDM DO D-3
aliases, SQL, see SQL, aliases
DO Index-1
allow promote to parent DO 3-20

ANALYZER cleared DO 5-6
ANALYZER hold DO 5-7
ancestor releases
illustrated DO 1-11
applications
identifying DO 1-2
archiving
deleting an object copy from library DO 3-46
mentioned DO ix
relationship of to release environments DO 1-4
associating
source and object when adding to an application DO
4-10
source with an object DO 4-10
attributes
object, see object attributes
authorities, System i
object, and Aldon LM(i) DO 1-13
B
base releases
defined and illustrated DO 1-10
illustrated DO 1-11
LM(i) supports unlimited number per application DO
1-10
objects presence in indicated on Aldon LM(i)
panel DO 2-8
required in forming application DO 1-10
based on residence status field DO 4-7
binding directories
assigning DO 2-13
completing object dependency data DO 4-20 to DO
4-24
BND extended attribute value for ILE DO 4-11
converting back to OPM from DO 4-13
C
cancel requests or clear conditions DO 5-5
CCFMPRTDVO - Confirm Print of List Report DO 6-3
Change *CONTAIN Creation Options panel DO C-10
Change Checked Out Object panel DO 4-10
Change Object Creation Options panel DO 4-17
change object data option DO 2-7
changing
checked out objects, see changing, object descriptions
library group assignments DO 3-42
object attributes DO 4-11
object descriptions DO 4-9
object library groups DO 3-38
object source files DO 3-38
object source members DO 3-38
user defined options DO D-3
DO Index-2
checking out
child release, recommendation DO 3-10
dependent objects DO 4-26, DO 4-28
by adding to a checkout list DO 3-6
groups of objects DO 1-9
with or without task association DO 3-6
checkout
act on objects using DO 3-8
available interfaces DO 3-6
conflict DO 5-9
discussed DO 3-2 to DO 3-6
eligible agents DO 3-3
eligible objects DO 3-3
eligible recipients DO 3-3
introduced DO viii, DO 1-6
object flow during DO 3-4
overview DO 3-2
ownership and authority assignments during DO 3-5
checkout objects report - PRTFCHKOUT DO 6-6
checkout report - PRTFCHKOUT DO 6-6
checkouts
transferring to different developer DO 3-9
child releases
checking out logical files with physical files DO 3-10
illustrated DO 1-11
merging to parent release DO 2-13
child vs. delta DO 3-19
CMOVOBJDSC DO 3-42
CMRGOBJPRN DO 3-27
CMRGSRC DO 5-14
commands
ACMSVFYAPP (verify release)
ACMSVFYAPP command (verify release) DO
5-16, DO 5-18, DO 5-19
common installation library
STRALDPRD command DO 2-1
Community Manager
access from Aldon LM(i) DO 1-9
compare DO 5-13, DO 5-17
conditions
creation of objects not inhibited by DO 4-5
working with DO 5-2
conditions defined DO 5-2
Confirm Delete of Objects panel DO 3-45
Confirm Print of List Report - CCFMPRTDVO DO 6-3
conflict types DO 5-9
conflicts
checkout DO 5-9
checkout, identified DO 5-11
resolving conflicts DO 5-11
container files, see *CONTAIN files
copying
PDM-style option files DO D-3
create commands
see creating objects, create commands DO 4-6

Create Object Report - PRTFCREATE DO 6-7
Create Objects panel DO 4-7
Create* DO 2-11
Creating
user options DO D-11
creating
checkout requests DO 3-6
promotion requests DO 3-18
Creating objects
authority required DO 4-5
eligibility rules for DO 4-4
ILE programs DO 4-8
non-resident DO 4-6
overview DO 1-12
set up for logical files that reference logical files DO
4-8
creating objects
*CMD objects in development DO 4-7
command defaults DO 1-12
command definitions DO 1-12
create command selected automatically DO 4-6
dependent DO 4-26
overview DO 1-12
cross-reference files, third party
automatic update during promotes DO 3-17
CRTDUPOBJ DO 3-26
CSBMJOBLBL DO 3-28
CSELCHGCRT DO 4-18
CSELRELLGP DO 3-42
Custom Reports DO 6-2
D
data library update failure DO 5-6
data on promotion, handling DO 3-16
data option DO 2-7
Data sets
file descriptions updated automatically on
promotion DO 4-5
Defaults
object ownership and authorities DO 1-13
Define *RCDS Object panel DO C-7
Define Module Object panel DO 4-12
Defining
user options file to Aldon LM(i) DO D-15
delete changed object of cleared conflict DO 5-10
delete conflict DO 5-10
Delete Development Log Entries panel DO 4-38
delete from environment conflict DO 5-10
Deleting
development log entries DO 4-38
deleting
archived objects DO 3-46

objects DO 3-45
delta release data hold DO 5-7
delta releases
defined and illustrated DO 1-10
illustrated DO 1-11
LM(i) supports unlimited number per application DO
1-10
objects presence in indicated on Aldon LM(i)
panel DO 2-8
Dependent objects
acting on
subsetting lists of DO 4-29
dependent objects
acting on DO 4-28
checking out DO 4-28
creating DO 4-28
leaving resident on promote DO 3-15
lists of DO 4-28
promoting DO 4-28
deploying
on promote
to parent DO 3-24
Deployment
overview DO 1-8
descendent releases
illustrated DO 1-11
Developers DO 1-14
developers
changing DO 3-9
transferring checked out objects DO 3-9
development environment
introduced DO 1-3
Development log
deleting records from DO 4-38
Development creates not included in DO 4-33
printing reports from DO 4-34
selecting records in for display by release
relationship DO 4-34
viewing object histories for multiple objects in DO
4-32
development log DO 1-9
development log action codes DO 4-35
Development Log Entry Detail panel DO 4-34
Development Log Report - PRTFDSPLOG DO 6-9
Development Log, using the DO 4-32
development tools
user defaults DO 2-4
Display Development Log panel DO 4-33
E
Editing objects
System i *MENU objects
DO Index-3
using the pseudo-source method DO B-12

editing objects
System i *MENU objects DO B-6
emergency acknowledgement DO 5-6
emergency checkout conflict DO 5-9
emergency checkouts DO 3-18
promoting objects after DO 3-18
Environments
Aldon LM(i) DO 1-3
Development DO 1-3
Integration DO 1-4
Production DO 1-4
environments
quality assurance DO 1-4
extended attributes, see object extended attributes
F
failure condition
data library update DO 5-6
Flow charts
Aldon LM(i) Environments DO 1-3
flow charts
object movement DO 3-4, DO 3-12
foreign checkout conflict DO 5-10
fulfilling
checkout requests DO 3-6, DO 3-8
promotion requests DO 3-18
functions, SQL, see SQL, functions
G
global user defaults DO 2-3
global view DO 2-3
H
Harmonizer
comparing Harmonizer
merging DO 5-13, DO 5-17
Help text
function key access to DO F-8
mentioned DO ix
hot keys DO 2-5
How to
view
object histories for multiple objects DO 4-32
how to
merge objects
into parent of a delta DO 3-27
promote objects
to parent of a Delta DO 3-21
start Aldon LM(i)
from the Aldon products menu DO 2-1
I
ILE programs
DO Index-4
accelerating execution of SQL statements in, see SQL,

packages
completing object dependency data DO 2-13, DO
4-20 to DO 4-24
converting back to OPM from BND DO 4-13
converting programs to DO 4-11
creating DO 4-8
extended attribute values for DO 4-11
modifying and testing DO 3-44
modifying and testing modules for DO 3-44
indexes, SQL, see SQL, indexes
installing live
additional features DO 3-29
by task DO 3-29
changing default data conversion specifications DO
3-33
changing default installation method DO 3-31
changing default schedule DO 3-30
changing the comment DO 3-30
clearing invalid requests DO 3-37
controlling content installed DO 3-29
fulfilling requests DO 3-36
requesting DO 3-34
to multiple targets per environment DO 3-29
Integration (Aldon LM(i) environments)
discussed DO 1-4
L
leave resident
purpose of DO 3-15
Librarians DO 1-15
library groups
changing for a group of objects DO 3-42
changing for an object DO 3-38
changing for an objects source DO 3-38
load conflict DO 5-10
log, development DO 1-9
Logical files
referencing other logical files, set up for creation
of DO 4-8
logical files
checking out with physicals for child release DO
3-10
promotion of DO 3-13
M
Managers DO 1-15
merge DO 4-37, DO 5-13, DO 5-17
objects into parent vs. promote DO 3-26
selected objects by batch job DO 3-26
selecting objects DO 3-26
task/release connections DO 3-26
merge modified source DO 5-13
Merge Objects into Parent panel DO 3-27

Merge Source panel DO 5-13, DO 5-14
merge to parent
version number DO 4-37
merging
log entries DO 3-26
to parent
how to DO 3-27
More Functions panel DO 2-4
Move/Define Object in Descendent Release DO 3-42
Move/Define Objects (Library Groups) panel DO 3-43
Move/Define Objects panel DO 3-40, DO 3-42
moving
objects (checkout, promote, and related
functions) DO 3-1
objects to new library groups, source files, or source
members DO 3-38
multiple checkout conflict DO 5-9
N
Non-resident objects
creating to make resident, discussed DO 4-4
creating to make resident, library list for DO 4-4
creating, procedure for DO 4-6
non-resident objects
phantom objects defined DO 4-4
version numbers not incremented DO 4-5
notified releases
conflict records created on promote to parent DO
3-20
O
object attributes
changing DO 2-11, DO 4-9, DO 4-11
changing when converting to ILE DO 4-13
conversion of program to ILE DO 4-11
object creation commands DO 1-12
role in auto selection of create commands DO 4-6
Object dependency data
specifying manually DO 4-19
using DO 4-26
when obtained DO 4-18
object dependency data
completing for ILE DO 4-20 to DO 4-24
completing for ILE binding directories, programs and
service programs DO 2-13
object deployment, see deploying and deployment
object descriptions
changing DO 4-9
object extended attributes
changing DO 4-9
changing to convert a program to ILE DO 4-11

changing when converting from BND back to
OPM DO 4-13
changing when converting to ILE DO 4-11, DO 4-12
identifying the program model as ILE DO 4-14
role in identifying program model as ILE DO 4-9
Object movement DO vii, DO 1-6
object version number DO 3-26
objects
adding DO 4-13
changing production locations DO 3-38
Objects with residence status field (Create Objects
panel) DO 4-7
OPM extended attribute value for ILE DO 4-11
OPM extended attribute value for ILE programs
converting back to from BND DO 4-13
Options
PDM style, and Hawkeye Pathfinder interface DO
D-1
Other Setup Recommendations for ILE Objects DO
4-24
Overview
Aldon LM(i) environments DO 1-3
releases DO 1-9
Ownership
of objects DO 1-13
P
packages, SQL, see SQL, packages
Page headings (for Reports) DO 6-1
Panel interface DO F-1
panel specific subsetting DO 2-5
panels
Act upon Dependent Objects DO 4-28
Add Release Object DO C-6
Aldon LM(i) main menu DO 2-2
Change *CONTAIN Creation Options DO C-10
Change Checked Out Object DO 4-10
Change Object Creation Options DO 4-17
Confirm Delete of Objects DO 3-45
Create Objects DO 4-7
Define *RCDS Object DO C-7
Define Module Object DO 4-12
Delete Development Log Entries DO 4-38
Development Log Entry Detail DO 4-34
Merge Objects into Parent DO 3-27
More Functions DO 2-4
Move/Define Object in Descendent Release DO 3-42
Move/Define Objects DO 3-40, DO 3-42
Move/Define Objects (Library Groups) DO 3-43
request checkout DO 3-7
Select Copy of Object to Delete DO 3-46
DO Index-5
Set User Options DO D-15

Set User-Defined Option File DO D-15
Specify Library Groups for Descendent Releases DO
3-42
Submit Job with Varying Library Lists DO 3-28
Subset Dependent Objects List DO 4-29
subset objects by release list DO 2-15, DO 2-17
Transfer Objects DO 3-9
Work with Binding Directories DO 4-22
Work with Objects by Developer DO 4-2
Work with Objects by Release DO 2-9
Work with Requests and Non-Conflict
Conditions DO 5-4
parent releases
illustrated DO 1-11
PARLENV DO 2-16
Pathfinder
HAWKBAR menu access DO 2-4
user-option interface DO D-1
PDM-style user options DO D-1 to DO D-15
using from Aldon LM(i) panels DO 2-14, DO D-1,
DO D-11
phantom objects
considered non-resident DO 4-4
create function DO 4-4
physical files
checking out with logicals for child release DO 3-10
point and shoot orientation DO ix
PowerHouse
access to from DO 2-4
preface DO vii
Print source DO 2-10
procedures, SQL, see SQL, procedures
production environments
preventing level checks DO 4-4
Production libraries
number supported DO 1-4
promote
to parent function DO 3-19
promote from child conflict DO 5-9
Promote Object Report DO 6-7
Promote/Create Object Report DO 6-7
promoting
access to the function DO 3-18
automatic update of third party files DO 3-17
creating vs. moving objects DO 3-12 to DO 3-14
dependent objects DO 4-26
eligible agents DO 3-11
eligible objects DO 3-10
from child DO 3-21
interfaces available DO 3-17
leaving objects resident DO 3-15
level checks caused by, resolving DO 3-14
DO Index-6
logical files, automatic coordination DO 3-16

object flow during DO 3-12
object movement, diagram DO 1-6
overview DO 3-10, DO 3-17
ownerships and authorities managed by Aldon
LM(i) DO 3-15
physical file prevented by link to logical outside of
Aldon LM(i) DO 3-15
physical files, automatic coordination DO 3-15
place of DO viii
session protection during DO 3-12
to parent DO 4-31
capabilities and features DO 3-19
discussed DO 3-19 to DO 3-24
effects of DO 3-19
how to DO 3-21
prerequisite for requesting DO 3-25
prerequisites DO 3-20
promotion, handling data DO 3-16
PRTFCHKOUT - checkout report DO 6-6
PRTFDSPLOG - Display Development Log Report DO
6-9, DO 6-10
PRTFDVPOBJ - Work with Objects by Developer
report DO 6-4
PRTFPROMOT - Promote Object Report DO 6-7
PRTFPRTOBJ - Object Data Report DO 6-8
Pseudo-source
determining whether used for an object DO A-3
discussed DO A-2
working with, additional details DO A-2
Q
quality assurance
discussed DO 1-4
quality assurance personnel, authorizing DO 1-15
R
record objects DO C-2
reference libraries
introduced DO 1-13
reference objects
introduced DO 1-13
release checkout conflict DO 5-9
Release Conflict (REL) DO 5-9
release levels
indicated on Aldon LM(i) CWRKOBJREL panel DO
2-8
release view DO 2-16
Releases
overview DO 1-9
remote developers
objects not scanned DO 4-19
remove a data set update failure DO 5-6
Reports DO 6-1
Create Object Report DO 6-7

Display Development Log DO 6-9, DO 6-10
Object Data Report DO 6-8
Promote Object Report DO 6-7
Promote/Create Report DO 6-7
Work with Objects by Developer DO 6-4
reports
checkout report DO 6-6
request and non-conflict conditions DO 5-5
Request Checkout panel DO 3-7
request conditions
checkout DO 5-5
request for checkout DO 5-5
request for install live DO 5-5
request for promotion DO 5-5
request for promotion to parent release DO 5-6
requests
install live DO 5-5
promote to parent DO 5-5
promotion DO 5-5
residence status field (Subset Objects by release
panel) DO 2-16
retired object DO 2-7
S
scanning
remote developer DO 4-19
Screen Design Aid tool
setting display vs. menu default DO 5-12
Select Copy of Object for Change of Creation Options
panel DO 4-18
Select Copy of Object to Delete panel DO 3-46
Service programs
adding SQL DO G-2
and SQL packages DO G-3
Set User Options panel DO D-15
Set User-Defined Option File panel DO D-15
sibling releases
illustrated DO 1-11
Single-copy create specifications
creating DO 4-16
deleting DO 4-18
source code
files, changing for an object DO 3-38
members, changing for an object DO 3-38
Specify Library Groups for Descendent Releases DO
3-42
SQL
adding objects DO G-2, DO G-3
aliases DO G-2
functions DO G-2
indexes DO G-2
object text acquisition and display DO G-4

packages DO G-2, DO G-3 to DO G-4
procedures DO G-2
service programs, adding DO G-2
tables DO G-2
triggers DO G-2
types, user defined DO G-2
limits of Aldon LM(i) current support DO G-3
views DO G-2
SSA compliance DO ix
starting
LM(i) from the Aldon products menu DO 2-1
STRALDPRD command
start Aldon products DO 2-1
Submit Job with Varying Library Lists panel
CSBMJOBLBL DO 3-28
Subset Conflicts List panel DO 5-8
Subset Dependent Objects List panel DO 4-29
subset objects by release list panel DO 2-15, DO 2-17
Subset Requests and Non-Conflict Conditions List
panel DO 5-4
Subsetting
dependent object lists DO 4-29
subsetting
work with... panels DO 2-15
Substitution Variables Supported table DO D-12
System i *MENU objects based on pseudo-source
editing DO B-12
System i menu objects
adding to Aldon LM(i) DO B-3
adding using pseudo-source DO B-8
T
tables, SQL, see SQL, tables
tasks
adding when defining new objects DO 4-15
testing
create non-resident function DO 4-4
ILE modules DO 3-44
ILE programs DO 3-44
preventing level checks DO 4-4
Tracking
object status DO 1-9
Transfer Objects panel DO 3-9
triggers, SQL, see SQL, triggers
Types of objects supported DO 1-5
types, SQL user defined, see SQL, types, user defined
U
user classes
predefined DO 1-14
user defaults
DO Index-7
*USERDFT
subsetting using DO 2-15
option 19=Alt edit response when *FILE DSPF
ambiguous DO 5-12
user defined create commands
selected automatically DO 4-6
user defined options DO D-11
Aldon LM(i) panels DO D-1
changing DO D-3
PDM and Pathfinder DO D-1
users
authority options DO 2-14, DO 3-5
authority options for promote function DO 3-17
users (Aldon LM(i))
discussed DO 1-14
V
version numbers
incrementing rules DO 4-37
views, SQL, see SQL, views
W
Work with Binding Directories panel DO 4-22
Work with Objects by Developer panel DO 4-2, DO 4-3
Work with Objects by Release panel DO 2-9
Work with Objects by Release panel options
* (after an option description) DO 2-9
10=specify data conversion DO 2-10
11=print attributes DO 2-10
12=work with conditions DO 2-11, DO 2-12
13=request checkout* DO 2-11
15=change create options DO 2-11
16=change DO 2-11
17=request promote* DO 2-11
18=work with tasks DO 2-11
19=alternate edit DO 2-11
2=edit DO 2-9
20=scan for requisite objects* DO 2-11
23=check out (emergency)* DO 2-12
24=work with archive DO 2-12
25=retire DO 2-12
27=promote to parent* DO 2-12
29=move/define (library groups)* DO 2-12
3=check out DO 2-10
30=display log DO 2-12
32=change create overrides DO 2-12
35=Compare DO 2-12
37=request promote to parent* DO 2-12
39=display requisite objects DO 2-13
4=delete DO 2-10
40=define requisite objects DO 2-13
41=act upon dependent objects DO 2-13
42=act upon dependent objects* DO 2-13
DO Index-8
44=Deploy* DO 2-13
44=Work with deployment sets DO 2-13
45=assign binding directories DO 2-13
47=install live* DO 2-13
5=browse source DO 2-10
50=merge into parent* DO 2-13
57=request install live* DO 2-14
7=promote* DO 2-10
8=display attributes DO 2-10
9=move/define DO 2-10
99=display LM(i) blocking where used... DO 2-14
XX=user defined PDM-style options DO 2-14
Work with Requests and Non-Conflict Conditions DO
5-4
Work with Requests and Non-Conflict Conditions panel
WRKCND DO 5-4
Work with... panels DO 2-5
working with
*RCDS objects DO C-11
dependent objects DO 4-18
object by release DO 2-6
objects DO 4-1
objects by developer DO 4-2
physical files for *RCDS objects DO C-5
System i menu objects DO B-6
System i menu objects based on pseudo-source DO
B-12

Detailed Aldon PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Detailed Aldon PDF

Uploaded by

Copyright:

Available Formats

Aldon LM(i) Daily Operations Reference

Daily Operations Reference

Aldon Lifecycle Manager

Aldon LM(i) Daily Operations

Copyright 1994-2007 by Aldon. All rights reserved.

Updated: August 8, 2007

Aldon LM(i) Daily Operations Reference

Daily Operations Reference

Introduction ........................................................................................................DO 1-1

Aldon LM(i) Daily Operations Reference

Introduction to Using Aldon LM(i) ................................................................... DO 2-1

Checking Out Objects ........................................................................................ DO 3-2

Aldon LM(i) Daily Operations Reference

Third Party Cross Referencing Files Update on Promotion to Production .DO

Working with Objects by Developer ..................................................................DO 4-2

Aldon LM(i) Daily Operations Reference

Working with Object Dependencies ................................................................ DO 4-18

What are Conflicts and Non-Conflict Conditions? ............................................ DO 5-2

Aldon LM(i) Daily Operations Reference

Overview of Reports ..........................................................................................DO 6-1

About Pseudo-Source ........................................................................................DO A-2

Developing System i Menus with Aldon LM(i) ................................................DO B-1

Overview ...........................................................................................................DO C-2

About PDM-Style User Options ........................................................................DO D-1

Aldon LM(i) Daily Operations Reference

Overview and General Instructions ..................................................... DO D-5

Introduction ........................................................................................................DO F-1

Adding SQL Objects ......................................................................................... DO G-2

Daily Operations Reference Index

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Daily Operations Reference

In the rush to meet implementation deadlines and to reduce growing data

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Daily Operations Reference

inquire about an individual task's status by focusing any of the

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Daily Operations Reference

Overview of Aldon Lifecycle Manager (System i Edition) DO 1-1

Applications and Releases

DO 1-2 Overview of Aldon Lifecycle Manager (System i Edition)

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Release Environments

**defined at application level

Figure 1 - Aldon LM(i) Environments

The following sections briefly describe each Aldon LM(i) environment.

Aldon LM(i) Daily Operations Reference

Overview of Aldon Lifecycle Manager (System i Edition) DO 1-3

DO 1-4 Overview of Aldon Lifecycle Manager (System i Edition)

Aldon LM(i) Daily Operations Reference

Aldon LM(i) Daily Operations Reference

Overview of Aldon Lifecycle Manager (System i Edition) DO 1-5

Aldon/CMS Environments and Object Movement

Access to Object Movement

DO 1-6 Overview of Aldon Lifecycle Manager (System i Edition)

Aldon LM(i) Daily Operations Reference

can restrict users from performing specific types of promotions. For

Aldon LM(i) Daily Operations Reference

Overview of Aldon Lifecycle Manager (System i Edition) DO 1-7

Emergency Checkout and Promotion

DO 1-8 Overview of Aldon Lifecycle Manager (System i Edition)

Aldon LM(i) Daily Operations Reference

User defaults: Rel:ALDON/ACMSDEMO/BASE Dvp:NONE Tsk:NONE

TOP, BOT, starting characters