LANSA

for i Introduction
Introduction to LANSA for i


About this Guide
Introduction to the LANSA Repository
Getting Started With LANSA
The LANSA Environment
Creating a LANSA Partitions
Building the LANSA Repository - Files
Building the LANSA Repository - Fields
Moving LANSA Objects Between LANSA Systems and Partitions
Transferring Complete LANSA Systems between IBM i Systems
Reorganizing the LANSA Internal Database
Backup and Recovery
LANSA Education


Edition Date October 21, 2014
© LANSA
About this Guide
Before you begin to use this guide, you may wish to review the following:
Who should use this Guide
How to use this Guide
Additional Information
For the latest product information and updates, please refer to the LANSA Web
site.
Who should use this Guide
This guide has been written for new LANSA developers who are beginning to
create their first applications using the LANSA for i development environment.
This guide describes the basic components of the application development
environment.
If you are a new LANSA developer, it is recommended that you try the Tutorials
supplied with the LANSA documentation.
How to use this Guide
The LANSA for i software should be properly installed and configured before
you use this guide. Refer to the Installing LANSA on IBM i Guide for
information.
Getting Started with LANSA defines the steps to allow developers and users to
access LANSA objects.
If you are using LANSA to extend an existing application, then Building the
LANSA Repository - Files provides you with the quick and easy way to make
your existing files known to LANSA. You will also find details about the
LANSA Repository features in this section.
Additional Information
For details about developing applications with LANSA, refer to the following
guides:
Installing LANSA on IBM i
LANSA for the iSeries User Guide
LANSA Technical Reference Guide
LANSA Application Design Guide.
For the latest product information, refer to the Web site resources on
www.lansa.com/support.
Your feedback will help us improve the overall quality of the LANSA
documentation and training. Please email your comments to
lansatraining@lansa.com.au

1. Introduction to the LANSA Repository
This chapter is intended to give you an understanding of the following topics:
1.1 What is the LANSA Repository?
1.2 What goes into a Field Definition?
1.3 What goes into a File Definition?
1.4 What is an I/O Module?
1.5 Why use the LANSA Repository?
Review Building the LANSA Repository - Files and Building the LANSA
Repository - Fields for details of how to load your files and fields into the
Repository.
1.1 What is the LANSA Repository?
The LANSA Repository is a central storage facility for reusable field and file
definitions.
Field definitions consist of all field related information, such as names,
descriptions, help text, validation rules and trigger actions. Any field,
whether used in a file or not, may be described in the Repository.
File definitions include the field related information as well as file level
validation rules and trigger actions, access routes and automatic
derivation/calculation of special fields.
These field and file definitions are available to all LANSA applications whether
these are executed on the IBM i or Windows. Other PC applications may also
use these definitions via LANSA's middleware, LANSA Open.
Repository descriptions, column headings and validations should be used for
any file or field on a screen or in a report, rather than specifying this
information in the specific program which displays the screen or produces the
report.
By using the Repository to store field and file definitions centrally, they are
easier to maintain and are used in a consistent way. For example, three different
LANSA functions or client applications, even if built by three different
developers, will be consistent because they use the same definitions for the
same pieces of data.
The LANSA Fundamentals iSeries Workshop available in classroom or self
study formats, covers all aspects of using the LANSA Repository.
1.2 What goes into a Field Definition?
When you are defining field definitions, you are really:
designing your screens
designing your reports
adding application logic.
In addition to the expected field attributes, LANSA field definitions include:
Descriptions
Labels, Column Headings, Default values & edit codes, etc.
Rules and Triggers
Validations to be checked and actions to be executed when adding, changing,
and deleting a field.
Help Text
Information at the field level for the user as well as technical information for
developers. (Help text is also used by LANSA's automatic documentation
facility.)
System Variables
Fields which are defined once and can be used across partitions.
All fields, including "working" fields should be defined in the Repository. After
a period of time, most working fields will be defined. Defining all fields in the
Repository will provide time savings for future projects as well as providing
comprehensive cross-referencing capabilities. The more field definitions entered
into the Repository, the higher the productivity gains.
Field definitions are stored in the Data Dictionary area of the Repository.
1.3 What goes into a File Definition?
Before explaining what goes into a file definition, it is important that you
understand the concept of a LANSA file definition and how this relates to the
IBM i concept of a file definition.
A 'file' is a normal IBM i database file, in which records can be retrieved, added,
changed or deleted.
To create a file, LANSA uses a file definition. In IBM I terms, a file definition
contains:
the fields that make up the format of the physical file records
logical views of the file. (These may contain select/omit criteria.)
LANSA's file definitions include:
physical files for tables
logical views.
As well, the LANSA file definition can also contain a number of LANSA file
features, such as:
validation rules
triggers (Rules and triggers can be recorded at both field and file level.)
virtual fields
batch control logic
access routes.
For more details about LANSA file definitions refer to the section What is a File
and What is a File Definition? in the LANSA for iSeries User Guide.
1.4 What is an I/O Module?
An I/O Module (also called an Object Access Module) is a program created by
LANSA to handle all access to files. Each file used by LANSA will have an I/O
Module whether created by LANSA or defined as an OTHER file used in
existing non-LANSA applications.
Each I/O module contains the Repository features defined for its file and fields.
Centralizing these features in an I/O module reduces the impact of file changes
on your applications. By channeling file access through the I/O module, whether
from a IBM i or client application, the validity of your data is protected because
it is always subjected to the same validation and security checks.
LANSA's I/O modules on the IBM i are compiled in RPG, making IBM i data
access via LANSA Open very efficient. An RPG compiler is therefore required
on the IBM i on which the Repository is maintained. (The compiler used for I/O
modules varies with the deployment platform).
The step that creates the I/O module is called "Making the file operational".
Some changes to the Repository definitions require the I/O module to be
regenerated and some do not. Following is a list of file and field changes
indicating whether the file needs to be "made operational" after the change, thus
regenerating the I/O module.
Files need to be "made Files do not need to be "made
operational" after changes to operational" after changes to these
these items: items:
Access Routes with Predetermined Access Routes without Predetermined
Join Fields Join Fields
Batch Control Authority
Default Values Column Headings & Labels
Field Length or Type Display Attributes
Logical View Edit Codes/Words
Physical File Help Text
Trigger Conditions Prompts
Trigger Points
 Validation Rules
Virtual Fields

1.5 Why use the LANSA Repository?
Using the LANSA Repository provides significant benefits to the development
of all applications, but in particular to client/server applications, which are often
created by a number of different developers or end user department personnel.
By using the LANSA Repository, you gain:
Consistency throughout your organization. A field or file definition has the
same description, validation and attributes, wherever it is used. This
consistency is a recognized factor in reducing user training.
Quality, because definitions, in general, are already in use and have been
tested. Unit and system testing turnaround is reduced.
Easier Maintenance as all fields and file related definitions are maintained
in one place.
Data Security as Repository validations and security levels are
automatically enforced in client applications in the same way as they are for
IBM i functions.
Impact Analysis, which allows you to quickly and accurately determine the
effects of changes to a field. For example, to determine which files and
LANSA functions use a particular field.
The Repository information is not only available to an application, but in some
cases it is actually enforced. Validation rules and security access, for instance,
cannot be bypassed by an application. Whether the IBM i data is manipulated
by a LANSA function or a client application via LANSA Open, the data must
adhere to the validation rules and security requirements defined in the
Repository.
If validation rules are not met, error messages defined in the Repository are sent
to the client application through LANSA Open. If a validation rule, error
message or help text is changed in the Repository, none of the client
applications need to be changed or recompiled. New or changed rules and help
text are picked up automatically.
Files defined in LANSA are standard IBM I files, accessible to non-LANSA
applications. Only the extra LANSA Repository facilities, such as validations
and virtual fields, help text, multilingual translation, and so on, are available to
applications developed using LANSA, or client applications accessing the IBM
i data via LANSA Open.
Conversely, files maintained by non-LANSA applications can be made known
to the LANSA Repository. All LANSA's Repository facilities can be added to
these files and used by the client application. This will not affect the original file
at all.
Re-using Repository information by a number of applications creates a need for
standards to be set and a commitment to be made to the use of these standards.
Some recommended standards are:
Files and fields are defined in one, and only one place.
All designers and application developers refer to this place for the definition.
Reference fields to be used wherever practical for dates and other standard
fields.
All application developers use a "corporate" vision when updating the
Repository. Every element in the Repository should be considered for
corporate use, not just for one screen in one program or application.
Security established to control not only what goes into the Repository, but
also who can change it.
Guidelines for field and file standard names can be found in the LANSA
Application Design Guide or the LANSA for iSeries User Guide.
2. Getting Started With LANSA
After installing LANSA for i and before beginning to populate the Repository,
you need to provide access to LANSA for the initial users.
This is a task normally completed by the person nominated as the LANSA
Administrator.
This section includes the steps required to define access to LANSA, as well as
an overview of the main LANSA system screens and LANSA's on-line help
facilities.
The following topics are included:
2.1 Accessing the LANSA system
2.2 LANSA Main System Menu
2.3 Housekeeping Menu
2.4 Allowing Users Access to LANSA
2.5 LANSA Help
2.6 The LANSA Online Guide
2.1 Accessing the LANSA system
Accessing LANSA for the first time
For the very first access to the LANSA system, you must sign on to the IBM i as
the user profile nominated as the LANSA partition security officer or the
LANSA system owner.
The LANSA partition security officer is specified when a partition is created.
The LANSA system owner user profile is specified during the installation
procedures. Refer to the Installing LANSA on IBM i Guide.
The LANSA partition security officer or system owner profile must be used to
allow other users to access LANSA.
The LANSA command
To access LANSA, execute the IBM i operating system command:
<library name>/LANSA
or
<library name>/LANSA DEVELOPER(A)
The <library name> is the name of the LANSA program library specified when
LANSA was installed.
For more information about the LANSA command, you may use the F4 prompt
key to display a complete list of parameters.
The 2.2 LANSA Main System Menu should now be displayed.
2.2 LANSA Main System Menu
The LANSA Main System Menu will appear something like this:

pppSYSMENU Main System Menu

Enter number of function or place cursor on same line and press Enter.

6 1. Use a process
2. Submit a process to batch
3. Field control menu
4. File control menu
5. Process control menu
6. Housekeeping menu
7. Display submitted jobs - workstation
8. Display submitted jobs - user
9. Display workstation message queue
10. Exit from LANSA


F1=Help F3=Exit F12=Cancel F14=Messages

To start, select the Housekeeping menu.

To do this, you can either
move the screen cursor down to the Housekeeping menu line and press Enter
or
you can enter the Housekeeping Menu's line number (6 in this example) and
press Enter.
The 2.3 Housekeeping Menu will then be displayed.
Note: The first 3 characters of the screen identifier show the partition in which
you are working. For example, the demonstration partition would be
DEMSYSMENU instead of pppSYSMENU, as shown in this example.
Some of the other facilities accessible from this menu are covered in later in this
guide.
2.3 Housekeeping Menu
The Housekeeping Menu provides access to the utilities which are used to set up
and maintain the LANSA environments.

pppHKPMENU Housekeeping Menu

Enter number of function or place cursor on same line and press Enter.

2 1. Review access to objects defined within LANSA
2. Review user access to LANSA system
3. Submit job to reorg LANSA internal data base
4. Change partition being worked with
5. Create or change system partition definitions
6. Work with partition multilingual attributes
7. Use the file maintenance utility
8. Work with list of objects to be exported
9. Import objects into this partition
10. Work with Application Template definitions
11. Use the dictionary conversion utility (if installed)
12. Create, review or run an online presentation
13. Work with multilingual development textual data
14. Work with tasks

F1=Help F3=Exit F12=Cancel F14=Messages

For details of all these options, refer to Housekeeping in the LANSA for i User
Guide.
Of particular importance when starting with LANSA are the first two functions.
These give users:
access to objects defined within LANSA, and
access to the LANSA system.
These options allow you to provide a secure LANSA environment. LANSA
provides security at field, file and function levels through these options and the
field and file options in the Repository. Refer to 2.4 Allowing Users Access to
LANSA.
In addition to changes made to LANSA from the Housekeeping Menu, there are
other important LANSA objects, such as the LANSA System Data Areas, which
affect the LANSA operating environment and its defaults.
2.4 Allowing Users Access to LANSA
To start, select the Review user access to LANSA system option on the
Housekeeping Menu and press Enter. A screen requesting that you specify the
name of the user is displayed:

USRACCESS Review / Change User Access

Enter user name whose access rights to LANSA
are to be displayed: ________


F1=Help F3=Exit F12=Cancel F14=Messages

Enter the user profile name of the user (e.g. QPGMR, QSYSOPR, SUSAN,
MURRAY, etc.) and press Enter. Note that the name can be no longer than 8
characters with routers using CPI-C communications. The Review / Change
User Access screen is displayed:

USRACCESS Review / Change User Access

Enter user name whose access rights to LANSA
are to be displayed: QPGMR

Allow
Menu name Description of menu entry Access
MAIN SYSTEM MENU
Use a process
Submit a process to batch
Field control menu
File control menu
Process control menu
Housekeeping menu
Display submitted jobs - workstation
 Display submitted jobs - user
Display workstation message queue
Exit from LANSA
PROCESS CONTROL MENU
Create a new process definition
Review or change a process definition
Delete a process definition
Compile a process from new or amended def. +

F1=Help F3=Exit F12=Cancel F14=Messages F21=Change

The Allow Access column indicates the user's current access to the related
LANSA menu or specific menu entry.
Note that when there is more than one page of a screen display, it is indicated by
a + sign at the bottom right of the screen. To scroll through all "pages", use the
roll up and roll down keys on your workstation.
Press the Change function key (F21) to make the screen input capable.

USRACCESS Review / Change User Access

Enter user name whose access rights to LANSA
are to be displayed: QPGMR

Allow
Menu name Description of menu entry Access
MAIN SYSTEM MENU
Use a process Y
Submit a process to batch Y
Field control menu Y
File control menu Y
Process control menu Y
Housekeeping menu Y
Display submitted jobs - workstation Y
Display submitted jobs - user Y
 Display workstation message queue Y
Exit from LANSA Y
PROCESS CONTROL MENU
Create a new process definition Y
Review or change a process definition Y
Delete a process definition Y
Compile a process from new or amended def. Y
Review, change or create process HELP text Y +

F1=Help F3=Exit F12=Cancel F14=Messages

Enter "Y" in each line in the column headed "Allow Access", as appropriate.
To remove a user's access to a specific menu item you simply blank out the
relevant "Allow Access" entry.
When a "Y" has been entered against every required menu entry, press Enter.
You will be requested to nominate the next user you wish to work with. Repeat
these steps until all users have been given access to LANSA.
When you have finished, use the Exit function key (F3) to return to the LANSA
Main System Menu.
If you would like more details, refer to User Access to the LANSA System in
the LANSA for i User Guide.
2.5 LANSA Help
The Help key (F1) has a number of uses within LANSA for i. Depending on the
location of your cursor at the time the help key is pressed, you can obtain:
the "second level text" of any message
information about LANSA itself from the Online Guide
developer written HELP text for fields defined in LANSA
user context sensitive field help text.
Messages are used extensively throughout the LANSA system. Refer to the
Messages and the HELP Key in the LANSA for i User Guide.
2.6 The LANSA Online Guide
The LANSA Online Guide provides a quick and convenient way of finding out
about a specific LANSA topic.
By pressing the HELP key at any time while working with a LANSA screen,
when the cursor is NOT on the same line as a message, a screen similar to the
one shown below is displayed.

SUBJECTS LANSA Online Guide ‑ Selected Subjects
Type action code next to each desired subject, then press Enter.
1=Display 5=Print
Action Subject
GETTING STARTED
_ What the Online User Guide is for
_ Introduction to LANSA
_ The Components of LANSA
_ Accessing LANSA
_ Selecting entries from the LANSA menus
_ Function keys
_ Messages and the HELP key
FIELDS
_ The field control menu
_ Selecting field(s) to be worked with
FILES
_ What is a file definition ?
_ Making a new file operational
_ Making an amended file operational +

F2=Ex Help F3=Exit F14=Messages F23=Contents

The list of topics initially presented will relate to the task being performed. You
can, of course, choose any other topic or display the complete contents of the
LANSA Online Guide.
The text of the Online Guide is taken from the LANSA for i User Guide and the
 RDML Technical Reference Guide. It covers all aspects of using LANSA on the
iSeries, including the development of applications.

3. The LANSA Environment
What is an environment?
Most operating systems support the concept of "environments" in one form or
another. Basically, having different "environments" in your system means that
one group of system users can work at what they are doing without being
disturbed by the existence of another group of users.
The classic two environment division is development and production.
Developers can work on a new version of a system in one environment while
the users run the current production system in another.
Environments may be real (physical constraints) or conceptual (understood
rules). For example, you might have two separate machines to separate
development and production. An application is created on the development
machine and then migrated to the production machine.
Alternatively, a single machine might be used on which different passwords and
libraries are set up. Where only one machine is available, the production and
development environments are usually separate libraries. Security is set up to
prevent developers from accessing production libraries and vice versa. Once an
application is complete, it is moved from a development library to a production
library.
There are two methods of creating multiple environments within LANSA:
Install multiple LANSA systems (refer to 3.1 What is a LANSA system?)
Install one LANSA system and then add partitions (refer to 3.2 What is a
LANSA Partition? and 3.3 About the SYS Partition).
The approach you use will depend upon site requirements. The preferred way to
do provide multiple environments within LANSA is by installing separate and
completely independent LANSA systems
In order to understand how systems and partitions are defined, refer to:
3.4 System and Partition Characteristics
3.5 LANSA System Data Areas
and
3.6 LANSA Partition Security Officer Profiles.
3.1 What is a LANSA system?
A complete LANSA system is comprised of the LANSA program library,
LANSA data library, and system partition library.
By loading a second set of these libraries (using different library names), you
install a second complete system.
When you installed the LANSA software onto your IBM i, these libraries are
supplied:
DC@PGMLIB The LANSA program library.
DC@DTALIB The LANSA data library.
DC@MODLIB The "SYS" or system partition library.

LANSA Program Library

The LANSA program library (DC@PGMLIB) contains the executable objects
that run the developer menus and panels. For example, the program which
allows you to enter field definitions is stored in this library.
LANSA Data Library
The LANSA data library (DC@DTALIB) contains the internal Database files
used by the LANSA software. The files in this library contain system level
information such as the definitions of all LANSA created objects. These
definitions are stored in internal LANSA files, with their partition identifier as a
part of the record key.
Note: The LANSA system objects are stored in two libraries to facilitate
backup. The LANSA program library only needs to be backed up infrequently.
However, the LANSA data library should be backed up regularly.
System (SYS) Partition Library
The "SYS" partition library (e.g. DC@MODLIB) for the common LANSA
system definitions.
Application Libraries
When you create new partitions, LANSA does not create the partition library or
libraries. You will have to manually create these libraries before you create the
partition, if they do not already exist.
The partition creation screen gives you the option of using one or two partition
libraries:
a "program" or executable objects library (Module library).
a library to contain the "data" objects (Default file library).
The program (module) library will contain the executable objects, such as
functions. It is also possible to specify that I/O Modules will be created in this
library, but, by default, they will be created with the file in the file library.
The "data" is the LANSA definition in Repository. The actual data files are
wherever you have created them. This data library is the default library for files,
but they can be located anywhere.
Only two libraries are generally needed when developing applications using
LANSA.
The module library is mandatory and is unique to the partition.
The data library can be the same as the module library or any library of your
choice.
3.2 What is a LANSA Partition?
A LANSA partition is a means of dividing up or "partitioning" one LANSA
system. Each partition is completely separate from other partitions.
Generally partitions are used to:
separate classes of users from one another (for example, separating
production from development although they should also be separate LANSA
systems.)
create "stand-alone" application systems or software packages.
With LANSA, you can create separate environments and partitions by either:
installing separate LANSA systems
or
configuring partitions within a LANSA partition.
Each time a developer invokes LANSA, an end-user runs a LANSA application
or accesses the IBM i using LANSA/Server or LANSA/Client, a partition
should be specified.
To invoke LANSA, the following command, which includes the partition, is
generally used:
DC@PGMLIB/LANSA PARTITION(_ _ _)
If no partition is specified, the SYS partition will be used by default.
What is in a Partition?
Technically, a partition is a set of libraries for storing your programs and data. In
addition, each partition or set of libraries must store the characteristics of the
environment. Characteristics which affect the applications developed are
defined at the partition level. These include security, defaults for function keys
and CUA compliance.
Functionally, a partition is an environment with its own set of objects and
LANSA "characteristics". For instance, each partition has its own Repository
(and if appropriate, processes and functions). Some optional facilities, such as
LANSA's Task Tracking and Documentor, are also installed at partition level.
For more information, go to 3.4 System and Partition Characteristics
Managing Partitions
LANSA provides a complete set of facilities to help System Administrators
manage partitions. For example, Import and Export, to allow objects to be
copied from one partition to another, or from one system or machine to another.
What is your Partition plan?
You should maintain separate LANSA development and production
systems.
This means more than just having separate development and production
partitions in one LANSA installation.
On the development system you could have:
DEM - demos, training, experimenting
DEV - development and maintenance of production systems
ACT - acceptance testing
SYS - LANSA system partition. Note: Each LANSA system must have a
SYS partition. A SYS partition is installed when you install LANSA.
On the production system you could have:
PRD - production systems
SYS - LANSA system partition.
You could even have a third "middle" system for consolidating and testing
completed development work.
The benefits of maintaining a separate LANSA development system are very
significant. Amongst other things, this gives you an opportunity to install,
configure and test new versions of LANSA or EPCs without affecting your
production systems. You can change system-wide System Variables, such as the
date, in order to test system changes without affecting the production system's
processes.
You minimize the possibility of production downtime by verifying that your
applications work correctly with the new software before deploying it to
production systems.
Second system? What to do?
It is easy to install an additional copy of LANSA for development purposes.
Assuming you are installing on a machine for which you are already licensed,
you do not need to pay additional license fees or to obtain new license codes.
You will need:
extra disk space.
the license codes issued for this CPU to be re-entered using the LANSA
License facility – if you still have the codes available. If not, you can request
 a re-issue of your existing license codes for this CPU from the LANSA
Licensing Department. You will re-enter the license codes after the new
LANSA system's install is complete.
Also see
3.3 About the SYS Partition
3.4 System and Partition Characteristics
3.3 About the SYS Partition
When the LANSA for i software is loaded, the partition SYS is installed.
Every LANSA System must have a SYS partition. This partition is used to store
the common LANSA system definitions information. You must not delete the
SYS partition.
You should also create other partitions as described in 3.2 What is a LANSA
Partition?
3.4 System and Partition Characteristics
LANSA allows you to set standard characteristics at
System level
Partition level.
System level characteristics are held in a series of Data Areas and are the same
for all partitions within a LANSA system. They include:
Field defaults
File defaults
Date format and century switch processing
IBM i operating system attributes
Security handling.
Partition level characteristics are specific to one partition only and include:
Function keys
Multilingual support
CUA standards
Documentor.
Initially, these default values are set by the LANSA system. In most cases, they
can be changed. For maximum efficiency, you should ensure that the default
values are set to the most common usage for your site.
3.5 LANSA System Data Areas
The System definition data areas are used to hold defaults and values (i.e.
parameters) used by LANSA in your installation. For example, when creating a
new field, several of the field definition characteristics are displayed with a
default value. These defaults are obtained from the relevant system definition
data area.
The maintenance of the LANSA system data areas should be assigned to the
LANSA System Administrator as one of the LANSA System Administrator's
tasks is to review and maintain the system defaults to ensure that they are
appropriate.
For details of these data areas and a comprehensive list of defaults, refer to
Review System Settings in the iSeries User Guide. You should change any data
area options via the System Setting dialogs.
3.6 LANSA Partition Security Officer Profiles
When you create a new LANSA partition, you will specify an existing IBM i
user profile that will be the partition security officer. This profile is granted
special rights to access information in the LANSA partition and LANSA
system. You will need to use this profile in order to perform certain
configuration tasks using the LANSA for the Web Administrator.
When you specify the IBM i user profile, you must check that the user profile is
properly defined. The LANSA partition security officer should be defined as
follows:
should include a job description with the correct library list (including
QGPL, QTEMP, and LANSA program libraries)
should have a minimum of *USER user class
should have special authority *JOBCTL and *SPLCTL
recommended that you use special authority *ALLOBJ
To display the current partition security officer, use the LANSA Housekeeping
Menu and select the Create or change partition definitions option.
4. Creating a LANSA Partition
To create a LANSA partition, you need to perform these steps:
4.1 Step 1. Create a New Library
4.2 Step 2. Create the New Partition
4.3 Step 3. Add Languages for Multilingual Use
The LANSA Development (DEV) partition is being created in this example.
4.1 Step 1. Create a New Library
To create a new partition you must sign on as the LANSA security officer. The
LANSA security officer is defined during the installation of the LANSA
software. The QSECOFR or QOTHPRDOWN user profiles are typically used.
For more details, refer to iSeries Requirements Checklist in the Installing
LANSA on IBM i Guide.
Use the IBM i CRTLIB command. Use the prompt key if you are unsure of the
parameters.
Library Name: LANSADEV
Library Type: *PROD
Description/text: LANSA development partition library
You must create a library to store the LANSA program objects and files which
you will create when developing your applications with LANSA. If you wish to
store the application data files in a separate library from the program objects,
you may wish to create a second library such as LANSADTA.
You will specify the LANSADEV library in 4.2 Step 2. Create the New
Partition.
4.2 Step 2. Create the New Partition
1. Sign on to LANSA using this LANSA command:
<library name>/LANSA
2. From the LANSA Main System Menu, choose the Housekeeping Menu.
3. From the Housekeeping Menu, choose the Create or change system partition
definitions option. The System Partitions panel is displayed with a list of the
existing partitions:

DC@P400402 System Partitions

Select partition to be reviewed, changed or deleted
Or use the ADD command key to add a new partition

Sel Partition Description
_ DEM Demonstration and Training Partition
_ SYS Major System and Application Partition



F1=Help F3=Exit F6=Add/Create F12=Cancel F14=Messages F17=LastActDtl

4. Select the Add/Create function key (F6), to create a new partition. The Add
System Partition screen is displayed:

DC@P400403 XXXXXXX System Partition

Partition identifier : XXX
Partition description : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Module library : XXXXXXXXXX
Unique object prefix : X
Security officer : XXXXXXXXXX
Default file library : XXXXXXXXXX Include in library list ? NO
 Initial public access : NORMAL Lib for Help Panel Groups: XXXXXX
Copy system fields from: SYS
SAA/CUA standards apply? YES
Multilingual support ? YES
Help option on menus : Display process or function HELP text
Return prefix on menus : Return to
Exit option on menus : Exit from system
Keep translated RPG ? NO in source file ______ in library _______
Keep translated DDS ? NO in source file ______ in library _______
Configure Task Tracking: NO / NO / NO / NO / NO / NO
Enable for full RDMLX : NO
Enable Documentor : NO

Fnn=Help Fnn=Exit Fnn=Cancel Fnn=Messages Fnn=LastActDtl

5. Change the entries on this screen to suit your requirements. For details of the
screen's entries, refer to System Partition Definitions in the LANSA for i User
Guide.
Multilingual support on IBM i
It is recommended that all partitions are defined as multilingual.
This means that an appropriate default language (and any other languages) must
be defined as described in 4.3 Step 3. Add Languages for Multilingual Use. You
must also specify the Add SAA/CUA Defaults that are included in this step.
In Visual LANSA a new partition is automatically defined as multilingual with a
default language created for the partition.
Unique object prefix
6. Choose a prefix which is unique for your site.
7. When you have checked or changed all the relevant entries, press Enter. The
Add SAA/CUA Defaults screen is automatically displayed.

DC@P400404 Add SAA/CUA Defaults

Partition id : DEV ‑ LANSA Development

Process menu style . . . . . . . . . . N N=Number C=Cursor
Process menu prompt line . . . . . . .:
Enter number of function required or place cursor on same line:_____
Process title in uppercase . . . . . . N Yes, No
Function title in uppercase . . . . . N Yes, No
Display panel identifiers . . . . . . Y Yes, No
Message line number . . . . . . . . . 22 22, 23, 24
Function key line number 1 / 2 . . . . 23 / 24 22, 23, 24
Show process date/time . . . . . . . . Y Yes, No
Show function date/time . . . . . . . Y Yes, No
Process auto‑record advance . . . . . Y Yes, No
Function auto‑record advance . . . . . Y Yes, No
Pull down auto‑record advance . . . . Y Yes, No
Window border fill characters . . . . ---- (Side, Top/Bottom,
Top corner,
Bottom corner)

F1=Help F3=Exit F12=Cancel F14=Messages

Window Border fill characters

8. Change to the characters you require, for example : . . : (colon, full stop, full
stop, colon). For other options, refer to Creating or Changing Partition
Definitions in the LANSA for i User Guide.
9. You should not have to change any other entries on this screen. Press Enter
to continue to the SAA/CUA Color Attributes Defaults. These are spread over
a number of panels similar to this one:

DC@P400405 Add SAA/CUA Color Attributes Defaults

Partition : DEV ‑ LANSA Development

Panel element/area and description Color Type/Attributes
ABCH Action bar and pulldown choices WHT Color: ___ ___ ___ ___ ___
 ___ ___ ___ ___ ___
Mono: HI_ ___ ___ ___ ___
PBPT Panel title BLU Color: ___ ___ ___ ___ ___
___ ___ ___ ___ ___
Mono: ___ ___ ___ ___ ___
___ ___ ___ ___ ___
PBPI Panel identifier BLU Color: ___ ___ ___ ___ ___
___ ___ ___ ___ ___
Mono: ___ ___ ___ ___ ___
___ ___ ___ ___ ___
PBIN Instructions to user GRN Color: ___ ___ ___ ___ ___
___ ___ ___ ___ ___ +

You can roll-up whenever you see a "+" in the right bottom corner.
You should not have to change any of the Color Attributes, as all fields
contain the SAA/CUA standard defaults.
10.Press Enter to continue to the Function Key defaults which are spread over 2
panels.

DC@P400406 Add SAA/CUA Function Key Defaults

Partition : DEV ‑ LANSA Development

SAA/CUA function key description Short form Default
Cancel current action Cancel 12
Enter any entry fields Enter RA
Request help for the current function Help 01
Display choices from a list of entries Prompt 04
Restore or refresh panel Refresh 05
Application defined messages key Messages 14
Scroll panel backward Bkwd 07
Allow entry of a command Command 09
Display cycle of function key area forms Keys 13
Exit to the highest level Exit 03
 Exit to the next level above Exit 03
Move cursor to first field on the screen Home HM
Scroll panel forward Forward 08
Display table of contents for help Contents 23
Provide information about entire panel Ex Help 02
Provide index of help information Index 11 +

Provide names and functions of keys Keys help 09
Scroll panel left Left 19
Re‑display last command that was issued Retrieve 09
Scroll panel right Right 20
Move cursor backward Switchbkwd 18
Move cursor forward Switch fwd 06
Move cursor to action bar Actions 10
Application defined add key Add/Create 06
Application defined change key Change 21
Application defined delete key Delete 22

F1=Help F3=Exit F12=Cancel F14=Messages

10.You should not have to change any of these entries, as all fields contain the
SAA/CUA standard defaults. Press Enter.
LANSA will now create the new partition.
After a short wait, you will be returned to the System Partitions list,
indicating that the new partition has been created.
11.Press the Cancel function key to return to the Housekeeping Menu.
Note: Before you can use the new partition, you may need to move (or
"import") some files, their definitions and data into it. To find out about the
LANSA facilities for moving objects between partitions, refer to The LANSA
Environment.
Go to 4.3 Step 3. Add Languages for Multilingual Use.
4.3 Step 3. Add Languages for Multilingual Use
If you have specified YES for Multilingual Support on the Add System Partition
screen in Step 2, you need to perform these steps to define the language you
require and provide translations for all menu options and function key
descriptions.
1. From the Housekeeping Menu, select the Change partition being worked
with option. The Systems Partitions screen is displayed with a list of the
existing partitions.
2. From the System Partitions list, select the partition to be worked with (in this
example DEV) and press Enter. The Housekeeping Menu will be displayed
for you to select the change you require.
3. Choose the Work with partition multilingual attributes option from the
Housekeeping Menu. The Multilingual Partition Languages screen, similar to
this example, will be displayed with the languages already available:

DC@P400501 Multilingual Partition Languages

Multilingual Partition : DEV

Select language to review/change or use Add key to add a new language

Sel Language Description Default
_ ENG English
_ DEU German YES
_ TCHI Traditional Chinese
_ HEB Hebrew +


F1=Help F3=Exit F6=Add/Create F12=Cancel F14=Messages

4. Press the Add/Create key to add a new language, or if you wish to

review/amend a language listed, select the language and press Enter.
 The Add or Review/Change Multilingual Partition Language screen will be
displayed, as appropriate.

DC@P400502 Display Multilingual Partition Language

Multilingual Partition . . . . . . : XXX

Language . . . . . . . . . . . . . . ENG
Language description . . . . . . . . English

DBCS support required . . . . . . . NO YES, NO
IGCCNV required . . . . . . . . . . NO YES, NO
Function key / description . . . . /
Line number . . . . . . . . . . .

RLTB support required . . . . . . . NO YES, NO

Default language . . . . . . . . . . YES YES, NO

Development language . . . . . . . . NO YES, NO

PC Locale uppercasing required . . . NO YES, NO

Fnn=Help Fnn=Exit Fnn=Cancel Fnn=Messages Fnn=Change Fnn=Delete

To add a new language, enter a four character identifier representing the

language you require and a description of the language.
5. Press Enter to continue to the Multilingual SAA/CUA Defaults.

DC@P400503 Display Multilingual SAA / CUA Defaults

Multilingual Partition . . . . . : XXX

Language . . . . . . . . . . . . . ENG
 Language description . . . . . . . English

Partition description . . . . . Demonstration and Training Partition

Process menu prompt line . . . . .
Enter number of function required or place cursor on same line.
Help option on menus . . . . . . . Display process/function HELP text
Return prefix on menus . . . . . . Return to
Exit option on menus . . . . . . . Exit from system
Library for Panel Groups . . . . .
User message files . . . . . . . .

iSeries EBCDIC CCSID . . . . . 00037
Windows ANSI code page . . . . 00819
Linux code page . . . . . . . 0000000000

Fnn=Help Fnn=Exit Fnn=Cancel Fnn=Messages Fnn=Change

6. Enter the text you require if you are creating a new language, or, if you have
selected an existing language, amend the text if required. Press Enter to
continue to the Multilingual Function Key defaults.
The Multilingual Function Key Defaults are spread over 2 panels. Use roll-
up to reach the next screen when there is "+" in right bottom corner.

DC@P400504 Add Multilingual Function Key Defaults

Multilingual partition . . . . . : DEV

Language . . . . . . . . . . . . . : GAL
Language description . . . . . . . : Gaelic

SAA/CUA function key description Short form Default
Cancel current action Cancel 12
Enter any entry fields Enter RA
Request help for the current function Help 01
 Display choices from a list of entries Prompt 04
Restore or refresh panel Refresh 05
Application defined messages key Messages 14
Scroll panel backward Bkwd 07
Allow entry of a command Command 09
Display cycle of function key area forms Keys 13
Exit to the highest level Exit 03
Exit to the next level above Exit 03
Move cursor to first field on the screen Home HM
Scroll panel forward Forward 08 +

DC@P400504 Add Multilingual Function Key Defaults

Multilingual partition . . . . . : DEV

Language . . . . . . . . . . . . . : GAL
Language description . . . . . . . : Gaelic

SAA/CUA function key description Short form Default
Cancel current action Cancel 12
Enter any entry fields Enter RA
Request help for the current function Help 01
Display choices from a list of entries Prompt 04
Restore or refresh panel Refresh 05
Application defined messages key Messages 14
Scroll panel backward Bkwd 07
Allow entry of a command Command 09
Display cycle of function key area forms Keys 13
Exit to the highest level Exit 03
Exit to the next level above Exit 03
Move cursor to first field on the screen Home HM
Scroll panel forward Forward 08 +



Display table of contents for help Contents 23
Provide information about entire panel Ex Help 02
Provide index of help information Help index 11
Provide names and functions of keys Keys help 09
Scroll panel left Left 19
Re‑display last command that was issued Retrieve 09
Scroll panel right Right 20
Move cursor backward Switchbkwd 18
Move cursor forward Switch fwd 06
Move cursor to action bar Actions 10
Application defined add key Add/Create 06
Application defined change key Change 21
Application defined delete key Delete 22

F1=Help F3=Exit F12=Cancel F14=Messages

7. Make changes as required. The standard defaults are displayed if the

language you have selected is already available. (In this example, the default
is English.)
8. Press Enter and the new language (Gaelic in this example) will be created.
After a short wait, you will be returned to the Multilingual Partition
Languages screen.
To add another new language, select the Add/Create key and repeat these steps.
When all required languages have been entered, press the Exit function key to
return to the LANSA Main System Menu.
For further information about the entries on this screen, refer to Partition
Multilingual Attributes in the LANSA for i User Guide.
5. Building the LANSA Repository - Files
Following is an overview of how to 5.1 Define Files in the LANSA Repository.
To define files to the Repository, you can either:
5.2 Make non-LANSA IBM i Files known to LANSA
or
5.3 Manually Create New Files with LANSA.
When a file has been defined, you will need to 5.4 Review the File Definitions.
5.1 Define Files in the LANSA Repository
You can add your file definitions to the LANSA Repository using one of the
following techniques:
Making existing non-LANSA files known to LANSA
If you are extending an existing application, such as a third party package, you
need to make the application's file definitions known to LANSA. This is done
using a process called "loading the definition" which creates field definitions
and physical and logical file definitions from your existing files. File definitions
can be loaded one by one as described in 5.2 Make non-LANSA IBM i Files
known to LANSA or as a bulk load as described in 5.2.3 Load (or Re-load)
Multiple File Definitions.
After loading the file definitions, you can add validation logic, as well as virtual
fields, field descriptions, column headings, defaults, help text, etc.
Files maintained by non-LANSA applications are sometimes referred to as
"external" or "other" files within the LANSA system.
Defining new files manually
Before a new file is created using LANSA, the fields within the file must first
be defined. Field descriptions, column headings, defaults, help text, etc. should
be added before the file is created. Field details can, of course, be finalized after
the file is created, as is done when creating files from "external" files. Refer to
5.3 Manually Create New Files with LANSA for the steps needed to create new
files.
5.2 Make non-LANSA IBM i Files known to LANSA
LANSA provides easy to use facilities to load the definition of existing IBM i
files and fields into the Repository. You can load your definitions:
one by one, as described in 5.2.1 Load a Single File Definition, or
in multiples, as described in 5.2.3 Load (or Re-load) Multiple File
Definitions.
There are no restrictions regarding naming conventions or file structure or any
restriction on the IBM i software used to create the application which owns the
file.
Since the physical file and any associated logical files already exist, you only
load the definition of the files into LANSA. You will continue to maintain the
definition of the file outside the LANSA system (i.e. in the DDS). Once the
file's definition has been loaded and the associated I/O module created, the file's
contents can be accessed through LANSA just like any other LANSA
maintained file.
Fields will be listed in the same way as for any LANSA file, but you will not
be allowed to change them. You will not be able to delete a field, add a field
or change the sequence.
Logical view definitions will be displayed, but you will not be allowed to
change them.
The Make File Definition Operational facility will never perform an action
that modifies the associated physical or logical database files in any way.
When a physical file is to be changed, you must change the definition outside
LANSA and then re-load it into LANSA as described in 5.2.2 Re-load a single
non-LANSA IBM i File Definition.
Note: An external file's attributes can be changed to allow you to
maintain it using LANSA, however, if you do this, you must be aware
of the consequences to existing applications that already use the file.

For more details about using existing files with LANSA, refer to these topics in
the LANSA for i User Guide:
Loading the Definition of a File NOT Maintained by LANSA
LANSA andOther System File Definitions.

5.2.1 Load a Single File Definition
You use these steps to make a single file definition known to the LANSA
Repository. This file has been created outside the LANSA system and will
continue to be maintained outside the LANSA system.
The main steps in making existing files known to the Repository are:
Step 1. Create the New LANSA File Definition
Step 2. Load (or re-Loading) the File Definition
Step 3. Review the File's Definition **
Step 4. Make the file Operational
** Step 3 is optional, but it is strongly recommended that you add these
facilities to your files.
Step 1. Create the New LANSA File Definition
1. Start from the Main System Menu.

pppSYSMENU Main System Menu

Enter number of function or place cursor on same line and press Enter.

4 1. Use a process
2. Submit a process to batch
3. Field control menu
4. File control menu
5. Process control menu
6. Housekeeping menu
7. Display submitted jobs - workstation
8. Display submitted jobs - user
9. Display workstation message queue
10. Exit from LANSA


F1=Help F3=Exit F12=Cancel F14=Messages

2. Select the File Control menu option.

3. From the File Control Menu select the Create a new file definition option.

pppFILMENU File Control Menu

Enter number of function or place cursor on same line and press Enter.

1 1. Create a new file definition
2. Review or change a file definition
3. Delete a file definition
 4. Make new or amended file definition operational
5. Print file definitions
6. Bulk Load of OTHER files
7. Exit from LANSA




F1=Help F3=Exit F12=Cancel F14=Messages

This option is used because you are creating a file definition that is new to
LANSA.
4. Press Enter and the Create New File Definition screen is displayed.

CRTFILE Create New File Definition

New file name . . . . . . . __________
Library of residence . . . __________
Description . . . . . . . . ________________________________________
Initial public access . . . NORMAL NORMAL, ALL, NONE
To be maintained by . . . . OTHER LANSA, OTHER

Copy file definition . . . __________
residing in library . . . __________




F1=Help F3=Exit F12=Cancel F14=Messages

5. Enter the Name of the file to be made known to LANSA, the Library it is in.
Add a meaningful Description and the Initial public access. The Copy file
definition is left blank as this is only used when copying LANSA files.
Specify OTHER in the To be maintained by option, to indicate that the file
will be maintained by some OTHER system.
6. Press Enter to create the definition of the file. (Note: The file has not been
loaded. Only the definition has been created.)
For further details about these entries, refer to the Creating a New File
Definition in the LANSA for i User Guide.
Go to Step 2. Load (or re-Loading) the File Definition.
Step 2. Load (or re-Loading) the File Definition
The detailed definition of the file must now be loaded into the LANSA
Repository. This loading process consists of populating the Repository with the
fields (field length, position in file, etc.) that make up the record layout of the
file and the logical files, if used.
1. From the File Control Menu select the Review or change a file definition
option.

pppFILMENU File Control Menu

Enter number of function or place cursor on same line and press Enter.

2 1. Create a new file definition
2. Review or change a file definition
3. Delete a file definition
4. Make new or amended file definition operational
5. Print file definitions
6. Bulk Load of OTHER files
7. Exit from LANSA



F1=Help F3=Exit F12=Cancel F14=Messages

This option is selected because the new file definition was created in the
previous step.
2. Press Enter and you are asked to nominate the file to be loaded:

pppSELFILE Select File to Work with

Enter full or partial name of the file definition(s) to be worked
with or leave blank to select from all file definitions _____________






F1=Help F3=Exit F12=Cancel F14=Messages

3. Select your file as described in 5.4.5 Nominate the File to work with. When
you have selected the file, press Enter and the File Definition Menu (Review)
is displayed.

pppFILREV File Definition Menu (Review)

Enter number of function or place cursor on same line and press Enter.

9 1. Review or change fields in file definition
2. Review or change logical views of file
3. Review or change file validation checks
4. Review or change access routes to other files
5. Review or change virtual fields
6. Review or change batch control logic
7. Review or change data base file attributes
8. Review or change file multilingual attributes
9. Load definition of file not maintained by LANSA
10. Exit from LANSA


File being worked with is . . . . : File Description
Name and library are . . . . . . : FileName Library


F1=Help F3=Exit F12=Cancel F14=Messages



4. Select the option to Load definition of file not maintained by LANSA and
press Enter to start the load process.
Logical Files
During the load process, logical file definitions are created, when applicable.
You will be given the option of retaining or rejecting each one. Rejecting a
logical view has no impact on any system other than LANSA.
Commit Amendments
5. Whenever you create or make modifications to a file definition, you are
prompted to commit the amendments.

COMMITAMD Commit File Amendment(s)


Commit amendment(s) . . . . . . . . . YES YES, NO



Fnn=Help Fnn=Exit Fnn=Cancel Fnn=Messages

Enter YES, otherwise you will lose all the changes you have made.
Note: If you are using Task Ids, then the relevant Task Identifier is displayed on
this screen.
Go to Step 3. Review the File's Definition.
Step 3. Review the File's Definition
After you have loaded the file definitions (i.e. made the file known to LANSA),
you should add the file validation rules and triggers, virtual fields, batch control
logic and so on. A brief description of some of these facilities is given in 5.4
Review the File Definitions.
At this stage, you should also review the field definitions and add descriptions,
validations, help text and so on. How to do this is described in Building the
LANSA Repository - Fields.
Whatever options you set for this file and its fields, the details will be
maintained purely by LANSA and have no impact on any "external"
applications that use the file.
Go to Step 4. Make the file Operational.
Step 4. Make the file Operational
Whenever you commit amendments you change the definition of the file. To
include these amendments in the I/O module which controls all access to the
file, you must make the file operational.
1. Return to the File Control Menu and select the Make new or amended file
definition operational option.

PppFILMENU File Control Menu

Enter number of function or place cursor on same line and press Enter.

4 1. Create a new file definition
2. Review or change a file definition
3. Delete a file definition
4. Make new or amended file definition operational
5. Print file definitions
6. Bulk Load of OTHER files
7. Exit from LANSA




F1=Help F3=Exit F12=Cancel F14=Messages

2. Nominate the file you wish to work with via the Select File to Work With
screens.
The Create/Recreate a File from its Definition screen is displayed:

DC@P200201 Create/Recreate a File from its Definition

File : FileName Library File Description

 Submit this job as described below . . . . . YES YES,NO
Using Job name . . . . . . . . . . . . . FileName
Job description . . . . . . . . . *LIBL/QBATCH
Job queue. . . . . . . . . . . . . *JOBD
Output queue . . . . . . . . . . *LIBL/QPRINT
Produce file and I/O module source listings. . NO YES,NO
Ignore decimal error/strip debug data options NO YES YES,NO
User program to call at completion . . . . . . ____________________
Object Library Type Action to be taken / reason(s)



F1=Help F3=Exit F12=Cancel F14=Messages

This step submits a job to create the I/O module for the file.
The File Name is inserted as the Job Name, which you can change, if you
wish.
3. Press Enter to submit the job.
Progress messages are displayed in the bottom section of the screen.
When the job has been successfully completed, the I/O module will include
all the file's and field's validations, default values, batch control logic, triggers
and so on.
To find out what else happens when a file is made operational, refer to
Submitting Job to Make File Definition Operational in the LANSA for i User
Guide.
5.2.2 Re-load a single non-LANSA IBM i File Definition
Whenever
the definition of an externally maintained file or one of its fields is changed
or
there is a change to the definition of a logical file
you must re-load the file's definition if these changes are to be applied to the
LANSA environment.
You can use the procedures described for loading a single file's definition or you
can use the much easier procedures which are described in 5.2.3 Load (or Re-
load) Multiple File Definitions.
To re-load a single file you will:
1. Choose the Load definition of file not maintained by LANSA option from
the File Definition Menu (Review).
2. Adjust the existing file or field definitions in the Repository, if necessary.
3. Make the File Operational.
When you re-load the definition of an existing IBM i file, any Repository
features you have already defined for that file will be retained.
If a field has been deleted from the external file's definition, it will be deleted
from the LANSA file definition during the re-load, but the related field
definitions will not be deleted from the Repository. Deleting the field must be
done manually if the field is no longer required.
Any file level rules or triggers that directly reference fields no longer in the file
definition are automatically deleted.
5.2.3 Load (or Re-load) Multiple File Definitions
The Bulk Load facility gives you the ability, in three simple steps, to make a
number of non-LANSA file definitions (sometimes called OTHER files) known
to LANSA.
You use this facility to load definitions that are new to LANSA as well as to
update definitions that have already been loaded.
To enable this facility for a partition, you must use the LANSA Import facility
and import from save file LS@BULKLOD.
The steps to load or re-load file definitions are:
Step 1. Create a list of files to be made known to LANSA.
Step 2. Select the files to be loaded or reloaded.
Step 3. Submit the batch job.
Step 1. Create a list of files to be made known to LANSA
To access this facility, select the Bulk load of OTHER files option from either
the File Control Menu or the Work with Files screen. The Bulk Load of OTHER
files screen is displayed.

LS@0001113 Bulk Load of OTHER files

Enter library which contains files . . . . . . . . PAYLIB
Enter full or partial name of file(s) to be worked with or leave blank
to select all . . . . . . . . . . . . . . . . . . . PR







Fnn=Help Fnn=Exit Fnn=Prompt Fnn=Cancel Fnn=Messages

Enter the search criteria for the OTHER files that you wish to work with. The
criteria consists of a library, which must be entered, and a file name. The file
name may be a full name, a partial name or blank.
Go to Step 2. Select the files to be loaded or reloaded.
Step 2. Select the files to be loaded or reloaded
All OTHER physical files matching the search criteria and their associated
logical files are displayed.

LS@0001158 Bulk Load of OTHER files

7=Load definition 27=Display details


File Library LANSA
7 PF PR0001 PAYLIB Y Personnel Details
_ LF PR0001L1 PAYLIB
7 LF PR0001L2 PAYLIB Y
7 PF PR0002 PAYLIB Employee History
7 LF PR0002L1 PAYLIB
_ LF PR0002L2 PAYLIB



Fnn=Help Fnn=Exit Fnn=Prompt Fnn=Cancel Fnn=Messages

The file details displayed are:

PF indicates that this is a physical file, LF indicates that this is a logical file
belonging to the previous physical file.
The IBM i file name.
Y in the LANSA column indicates that the file definition has previously been
loaded into LANSA.
The description of each physical file.
You can display the details of any file by entering option 27 (Display Details) to
the left of the file. The IBM i DSPFD details will be shown.
To load or re-load the definition, enter 7 to the left of each of the required files.
A logical file cannot be loaded by itself. It must be loaded with its associated
physical file. Not all logical files need to be loaded. Load only those which you
wish to use with LANSA.
Go to Step 3. Submit the batch job.
Step 3. Submit the batch job
You will be requested to enter the details to be used by the batch job that will be
submitted to load the definitions of the selected files.

LS@0001198 LOAD/CREATE OTHER FILES

Submit batch load of files selected . . . . . . . . YES YES, NO
Using Job name . . . . . . . . . . . . . . . . . . LS@BULKLOD
Job description . . . . . . . . . . . . . . . QUSRSYS/DC@JOBD
Job queue . . . . . . . . . . . . . . . . . . *JOBD
Output queue . . . . . . . . . . . . . . . . USRSYS/PRT02

Submit batch create of files after load . . . . . YES YES, NO
OPTIONS FOR BATCH CREATE
Produce file and I/O module source listings . . . . NO YES, NO
Ignore decimal error / Strip debug data option . . NO YES YES, NO
User program to call at completion . . . . . . . . __________



Fnn=Help Fnn=Prompt Fnn=Messages

During this same step, you can make the file(s) operational by entering YES for
Submit batch create of files after load. This will be cause a batch job to be
submitted for each physical file definition that is successfully loaded.
These make operational batch jobs will use the same Job description, Job queue
and Output queue that was used for the bulk load job. The Job name will be the
file name.
To find out what else happens when a file is made operational, refer to
Submitting Job to Make File Definition Operational in the LANSA for i User
Guide.
5.3 Manually Create New Files with LANSA
Before you can create a new file using LANSA, the fields in the file must first
be defined in the Repository. This process is described in Building the LANSA
Repository - Fields.
The steps in manually creating a new LANSA file are:
5.3.1 Step 1. Create the New LANSA File Definition
5.3.2 Step 2. Select the fields for the File
5.3.3 Step 3. Review the Definition (This step is optional, but it is strongly
recommended that you add these facilities to your files.)
5.3.4 Step 4. Make the file Operational.
5.3.1 Step 1. Create the New LANSA File Definition
1. Start from the Main System Menu.

PppSYSMENU Main System Menu

Enter number of function or place cursor on same line and press Enter.

4 1. Use a process
2. Submit a process to batch
3. Field control menu
4. File control menu
5. Process control menu
6. Housekeeping menu
7. Display submitted jobs - workstation
8. Display submitted jobs - user
9. Display workstation message queue
10. Exit from LANSA


F1=Help F3=Exit F12=Cancel F14=Messages

2. Select the File Control menu option.

Notify LANSA of the initial details of the file.
3. From the File Control Menu select the Create a new file definition option.

PppFILMENU File Control Menu

Enter number of function or place cursor on same line and press Enter.

1 1. Create a new file definition
2. Review or change a file definition
3. Delete a file definition
 4. Make new or amended file definition operational
5. Print file definitions
6. Bulk Load of OTHER files
7. Exit from LANSA




F1=Help F3=Exit F12=Cancel F14=Messages

4. Press Enter and the Create New File Definition screen is displayed.

CRTFILE Create New File Definition

New file name . . . . . . . __________
Library of residence . . . __________
Description . . . . . . . . ________________________________________
Initial public access . . . NORMAL NORMAL, ALL, NONE
To be maintained by . . . . LANSA LANSA, OTHER

Copy file definition . . . __________
Residing in library . . . __________


F1=Help F3=Exit F12=Cancel F14=Messages

5. Enter the new File's Name, the Library and Description. The file name must
be unique.
Initial public access specifies the access other users are to be given to the
file. NORMAL allows other users to add, change and delete records but not
modify the file's definition. ALL allows other users to add, change and delete
 records as well as modify or delete the file's definition. NONE prevents other
users any access to records in this file.
Specify LANSA in the To be maintained by . . option, to indicate that the file
will be maintained by LANSA.
The Copy file definition option allows you to create a new LANSA file
definition from another LANSA file definition. It does not allow you to copy
files defined outside of LANSA.
When you copy from an existing file definition, the following will be copied:
fields (including virtual fields), file level validations & triggers, batch control
and access routes. Logical views will not be copied.
6. When you have specified your entries, press Enter to start the creation of the
new file definition.
Commit Amendments
Whenever you create or make modifications to a file definition, you will be
prompted to commit the amendments.

COMMITAMD Commit File Amendment(s)


Commit amendment(s) . . . . . . . . . YES YES, NO



Fnn=Help Fnn=Exit Fnn=Cancel Fnn=Messages

Enter YES and Enter, to save the new file's definition. The File Definition
Menu (Create) screen is displayed.
Note: If you are using Task Ids, then the relevant Task Identifier is displayed
on this screen.
For further details about these entries, refer to Creating a New File Definition in
the LANSA for i User Guide.
Go to 5.3.2 Step 2. Select the fields for the File.
5.3.2 Step 2. Select the fields for the File
After you have committed your new file definition, the File Definition Menu
(Create) is displayed for you to select the fields which make up the record
layout.
Before you can do this, your fields must have been defined using the procedures
described in Building the LANSA Repository - Fields.
1. Select the Define fields in file definition option and press Enter.

pppFILREV File Definition Menu (Create)

Enter number of function or place cursor on same line and press Enter.

1 1. Define fields in file definition
2. Define logical views of file
3. Define file validation checks
4. Define access routes to other files
5. Define virtual fields
6. Define batch control logic
7. Review or change data base file attributes
8. Review or change file multilingual attributes
9. Load definition of file not maintained by LANSA
10. Exit from LANSA


File being worked with is . . . . : File Description
Name and library are . . . . . . : FileName Library

F1=Help F3=Exit F12=Cancel F14=Messages

The Display Fields in File Definition screen is presented.

DC@P200501 Display Field Definition

File : FileName Library File Description (Language)

Primary
Seq Name Description Key order Src






File FileName from Library currently has no fields defined in it.

F1=Help F3=Exit F6=Add/Create F12=Cancel F4=Messages

As this is a new file, there are no fields displayed.

2. Select F6 (Add/Create) and the Add Field Definition screen is displayed.

DC@P200501 Add Field Definition

File : FileName Library File Description (Language)

Primary
Seq Name Description Key order Src
___ ________ __
___ ________ __
___ ________ __
___ ________ __
___ ________ __
___ ________ __
___ ________ __
___ ________ __

File FileName from Library currently has no fields defined in it.

F1=Help F3=Exit F12=Cancel F4=Messages

3. You can choose to either:

enter the names of the fields to be included in the file
or
request a list of fields to select from.
If you choose to enter the field names, LANSA will attempt to find the
matching field details. If a name that you have entered happens to be a partial
name of another field, all the other fields containing the partial name will be
displayed with a message telling you what has been displayed. To request
a list of fields to choose from, in Name, enter:
? for a list of every field recorded in the Repository.
a partial name, for a list of the fields which match generically.
DEM has been used as the partial name in this example:

DC@P800501 Select Field from Data Dictionary





Either Choose field required from list below,
Or Enter a new full or partial search name : DEM

Sel Field Description Typ Len Dec
__ NAMCDE Name and Address Code A 11
__ DEMAD1 Address Line 1 A 25
__ DEMAD2 Address Line 2 A 25
__ DEMAD3 Address Line 3 A 25
__ DEMCAT Product Category A 13 +


F1=Help F12=Cancel F14=Messages

Select the fields for the file by entering a sequence number in the Sel
column. If you want different fields listed, use the Page Down key or re-enter
the selection criteria.
The fields you select are displayed immediately in the top half of the screen.

DC@P800501 Select Field from Data Dictionary

Type option, press enter 4=Delete from current list
Act Seq Field Description Typ Len Dec
10 NAMCDE Name and Address Code A 11
20 DEMAD1 Address Line 1 A 25
30 DEMAD2 Address Line 2 A 25
40 DEMAD3 Address Line 3 A 25



Full/Partial name of fields to be displayed from Data Dict ____________
Type option, press enter 1 to 99999=Select to add to current list
Sel Field Description Typ Len Dec
__ NAMCDE Name and Address Code A 11
__ DEMAD1 Address Line 1 A 25
__ DEMAD2 Address Line 2 A 25
__ DEMAD3 Address Line 3 A 25
__ DEMCAT Product Category A 13 +

F1=Help F12=Cancel F14=Messages

Continue selecting fields until you have selected all the fields that are
 required for the file.
Press Enter when you have completed your selection.
4. The Display Field Definition screen is now displayed with a list of your
selected fields:

DC@P200501 Display Field Definition

File : File Name Library File Name (Language)

Primary
Seq Name Description Key order Src
10 NAMCDE Name and address code 1
20 DEMAD1 Address line 1
30 DEMAD2 Address line 2
40 DEMAD3 Address line 3


F1=Help F3=Exit F12=Cancel F14=Messages F21=Change F22=Delete

5. Nominate the key fields by adding a sequence number in the Key Order
column.
You can delete fields from this list or change the sequence. If you have
duplicated a sequence number, the fields will be sorted alphabetically within
the sequence number.
6. Press Enter when you have completed the list. The File Definition Menu
(Review) is displayed.
Go to 5.3.3 Step 3. Review the Definition.
5.3.3 Step 3. Review the Definition
Add the file validation rules and triggers, define virtual fields, add batch control
logic, specify logical views, as required, selecting the options from the File
Definition Menu (Review).

pppFILREV File Definition Menu (Review)

Enter number of function or place cursor on same line and press Enter.

2 1. Define fields in file definition
2. Define logical views of file
3. Define file validation checks
4. Define access routes to other files
5. Define virtual fields
6. Define batch control logic
7. Review or change data base file attributes
8. Review or change file multilingual attributes
9. Load definition of file not maintained by LANSA
10. Exit from LANSA


File being worked with is . . . . : File Description
Name and library are . . . . . . : FileName Library

F1=Help F3=Exit F12=Cancel F14=Messages

A description of some of these functions is provided in 5.4 Review the File

Definitions.
Commit Amendments
Whenever you have made modifications to the file definition, you will be
prompted to commit the amendments.

 COMMITAMD Commit File Amendment(s)


Commit amendment(s) . . . . . . . . . YES YES, NO



Fnn=Help Fnn=Exit Fnn=Cancel Fnn=Messages

Enter YES, otherwise you will lose all the changes that you have made.
Go to 5.3.4 Step 4. Make the file Operational.
5.3.4 Step 4. Make the file Operational
Having defined the file and its fields and added the required Repository
features, you need to create the I/O module.
1. Return to the File Control Menu.

pppFILMENU File Control Menu

Enter number of function or place cursor on same line and press Enter.

4 1. Create a new file definition
2. Review or change a file definition
3. Delete a file definition
4. Make new or amended file definition operational
5. Print file definitions
6. Bulk Load of OTHER files
7. Exit from LANSA




F1=Help F3=Exit F12=Cancel F14=Messages

2. Select the option to Make new or amended file definition operational.

3. Nominate the file you wish to work with via the Select File to Work With
screens.
4. When you have selected your file, the Create/Recreate a File from its
Definition screen is displayed. The Job Name defaults to the File Name.

DC@P200201 Create/Recreate a File from its Definition

File : FileName Library File description

 Submit this job as described below . . . . . YES YES,NO
Using Job name . . . . . . . . . . . . . FileName___
Job description . . . . . . . . . *LIBL/QBATCH
Job queue. . . . . . . . . . . . . *JOBD
Output queue . . . . . . . . . . *LIBL/QPRINT
Produce file and I/O module source listings. . NO YES,NO
Ignore decimal error/strip debug data options NO YES YES,NO
User program to call at completion . . . . . . .. .
Object Library Type Action to be taken / reason(s)




F1=Help F3=Exit F12=Cancel F14=Messages

5. Press Enter to submit the job.

When the job has been completed successfully, the I/O module created will
include all the file and field validations, default values, batch control logic,
triggers and so on, that you have specified.
When LANSA creates a file it will make the record format name the same as
the file name. If you intend to write RPG programs to access files created
using LANSA, you can either:
change the file's record format name via the Database File Attributes
screen (selected from the File Definition Menu) before making the file
definition operational
or
rename the file record format within the RPG program itself.
You will find more information about creating files in the LANSA for i User
Guide:
Creating a New File Definition
Fields in the File Definition
Database File Attributes
Logical Views/Files Associated with a File Definition
Tips and Techniques for Defining Files Using LANSA.
5.4 Review the File Definitions
Once you have loaded an existing file's definitions or created a new file, you
may wish to add:
5.4.1 Field Validation Rules and Triggers
5.4.2 Help Text
5.4.3 Access Routes to other files
5.4.4 Predetermined Join Fields
Before your selected option screen is displayed, you will be asked to nominate
the file you wish to work with using the screens described in 5.4.5 Nominate the
File to work with.
Use as many file level validation checks as possible, as by doing so:
Most client/server applications can be written without any on-line validation.
The rules can be changed without modifying or re-compiling the application
programs which use the file.
The rules are standardized and can be tested by the application designer
before any application code is written.
The rules protect the database, even from a rogue application program.
You can find complete details of the Repository file options in Files in the
LANSA for i User Guide.
If possible, file definition maintenance should be assigned as a task to one
person within a project team or even to one person within an organization, to
ensure that:
All files (physical and logical) have accurate and concise descriptions.
The use of too many logical views is avoided. The maintenance of logical
file access paths (indexes) is probably the largest resource user on any IBM
i.
Error messages are standardized and consistent.
The steps to review the file definition are:
1. From the Housekeeping Menu select the File Control Menu line.
2. From the File Control Menu, select the Review or change a file definition
line.
3. Nominate the file you wish to work with via the Select File to Work with
screens.
4. The File Definition menu is displayed.
5. Select the required option from the menu and press Enter.
5.4.1 Field Validation Rules and Triggers
LANSA allows you to define validations to enforce business rules in the
Repository at both field and file level. If more than one validation is created at
file level, you control the order of these validation rules using a sequence
number.
File level validations are performed after field level validations. The sequence
of the validations is important.
Using LANSA's database triggers allow you to further reduce development time
by centralizing your application code. (You need a LANSA for i DEV license to
use LANSA's triggers.)
For details on performing specific tasks related to the validation rules and
triggers, it is necessary to review the descriptions of both field and file rules and
triggers. Refer to these topics in the LANSA for i User Guide:
Field Rules/Triggers in Fields
File Level Rules/Triggers in Files.
Learn about the use of validation rules and triggers in the LANSA Repository
by either attending a LANSA Fundamentals iSeries Workshop or using the self
study workshop provided with your LANSA system.
5.4.2 Help Text
Help text should be input for all fields in your files. There is no help text at the
file level.
A standard HELP text form should be set up and used as the basis for all field
level HELP text. Use of attributes and $$ substitution variables can vastly
reduce the amount of keying required to input a field's HELP text.
Refer to Messages and the Help Key in the LANSA for i User Guide to start
learning about the LANSA Help facilities on IBM i.
5.4.3 Access Routes to other files
Access routes are used to describe relationships between files within LANSA.
When using a query tool such as LANSA/Client, access routes are very
important because users do not need to understand the file structure. They only
need to nominate a "base" or "starting" file and LANSA can then follow the
access route chains to present the other accessible files as simple alternatives.
The relationship between records in any 2 files in any access route is predefined
as "1 : 1" or "1 : many". This enables the required screen formats to be
automatically designed for the type of information expected.
For example, an access path avoids the question "Given that I have a record
from file A, how do I access the associated records in file B"?
File A is always the file definition that is currently being worked upon. File B
can be any other physical or logical file known to LANSA.
File A can have many access routes. They could all be from file A to file B, or
some could be to any other file that is related to file A.
In addition, access routes can be assigned in a chain. Thus if there is an access
route from file A to file B, and an access route from file B to file C, then it is
possible to start with a record from file A and locate the associated record(s) in
file C.

When you load externally defined files into LANSA or create new
LANSA files, you must manually create access routes if you wish to
effectively use LANSA/Client or any other query facility over these
files.
5.4.4 Predetermined Join Fields
A Predetermined Join Field is used to hold the result of various operations
performed on information retrieved from a file nominated by the access route.
These operations can be TOTAL, MAXIMUM, MINIMUM, AVERAGE,
COUNT, and LOOKUP. The type of operations which can be performed depend
on the relationship between the files.
When the relationship is 1:1, using the key defined on the access route, a single
value will be retrieved and inserted into the predetermined join field. For
example, a product description can be retrieved for a product code (provided an
access route has been defined between an order file and the product description
file). A "keep last" value can be nominated to reduce I/Os, but only for 1:1
relationships.
When the relationship is 1:many (number of records is greater than 1) the
predetermined join field will hold the result of the selected operation. For
example the total of the line values from an order line file could be retrieved for
display with the order header file.
As a guide, do not access more than 10 to 15 files for predetermined join fields.
If the file to be accessed is a high speed table, the high speed table will be used,
thus reducing I/Os.
Refer to Access Routes to other Files in the LANSA for i User Guide or attend
the LANSA Fundamentals iSeries Workshop, to learn about predetermined join
fields and access routes and the steps involved in defining, reviewing or
changing them.
The LANSA Fundamentals iSeries Workshop is also available in a self study
format and is inlcuded with the LANSA documentation.
Access routes should not be confused with IBM i access paths.
5.4.5 Nominate the File to work with
Whatever method you use to create your LANSA files, once they have been
created or made known to LANSA, you will always follow the same steps to
select the file you wish to do further work with.
Because these steps are always the same, they are not repeated throughout this
chapter.
Wherever you need to specify the file to work with, you will work through the
following screens. In this guide, these steps are referred to as "nominate the file
you wish to work with".
Follow these steps to "nominate the file you wish to work with":
1. From the Main System menu, select the File Control Menu option.

pppFILMENU File Control Menu

Enter number of function or place cursor on same line and press Enter.

2 1. Create a new file definition
2. Review or change a file definition
3. Delete a file definition
4. Make new or amended file definition operational
5. Print file definitions
6. Bulk Load of OTHER files
7. Exit from LANSA




F1=Help F3=Exit F12=Cancel F14=Messages

Menu items 2 through to 5 will all request you to nominate the file you wish
to work with. In this example, select the Review or change field definitions
 option and press Enter.
2. The Select File to Work with screen is displayed.
Note: The partition in which you are working will replace the ppp shown in
this screen's identifier. For example, the demonstration partition would be
DEMFILMENU.

pppSELFILE Select File to Work with
Enter full or partial name of the file definition(s) to be worked
with or leave blank to select from all file definitions ____________






F1=Help F3=Exit F12=Cancel F14=Messages

3. Specify:
the name of the file you wish to work with
part of the name, to obtain a list of the files with names which generically
match the characters entered
leave the name blank, to obtain a list of all files.
If you did not specify an actual file name, the screen is returned with a list of
files, as shown in this example with the partial file name DEM:

SELFILE Select File to Work with

Enter full or partial name of the file definition(s) to be worked
with or leave blank to select from all file definitions . . DEM

Sel File Library Description
_ DEMDIVN DC@DEMOLIB Table of valid company divisions
 _ DEMHEAD DC@DEMOLIB Demo Order Header File
_ DEMLINE DC@DEMOLIB Demo Order Lines File
X DEMNAME DC@DEMOLIB Demo Names File
_ DEMPROD DC@DEMOLIB Product master file



F1=Help F3=Exit F12=Cancel F14=Messages

4. Roll up and down the list using your Up/Down arrow keys, if the list extends
over one page.
You can change your selection to repeat the search, if required.
5. Select a file to work with by placing any character in the Sel column on the
same line and pressing Enter.
Once you have nominated the file you wish to work with, the File Definition
menu is displayed for you to choose which action you wish to take.

6. Building the LANSA Repository - Fields
This chapter explains:
6.1 Four Ways to Create Fields
6.2 Create New Fields
6.3 Modify Field Definitions
6.4 Add or Modify Field Options.
6.1 Four Ways to Create Fields
You can create a new field by:
Copying from an existing LANSA field
Copying from an external (non-LANSA) field
Making existing files known to LANSA
Manually entering all the details
Copying from an existing LANSA field
Nominate the field you want to copy from. The existing field's definitions will
be automatically copied to the new field. You can also choose to copy all of the
validation rules and triggers, help text and multilingual definitions from the
existing field, or you can selectively copy the features you need for the new
field. You may review the copied details and change them as necessary.
Copying from an external (non-LANSA) field
Simply nominate the field, file and library you wish to copy from, and then add
the description, label and so on. You may also add any other Repository features
required for the new field.
Making existing files known to LANSA
If your field definitions were created when the files of your existing non-
LANSA application were loaded into the Repository, you will use the
Modifying Field Definitions steps to add the required LANSA features.
Manually entering all the details
Using the Add Data Dictionary Field screen, you may enter the details required.
You can reduce the actual number of entries when manually creating fields by
basing your new fields on purpose-built Reference Fields.
Reference Field: You can specify a link from your new field to another field of
the same size and type. The linked field is called a Reference Field. This linking
allows you to selectively copy the referenced field's validations and associated
error messages, help text, rules and triggers, and multilingual definitions to your
new field. Linked fields are similar to a copy, except that the two fields are
permanently linked together. Should certain aspects of the reference field
change, these changes will be automatically reflected in all the fields that are
linked to it.
You will find a more detailed description of Reference Fields at the end of this
chapter. For further information, refer to Fields in the LANSA for i User Guide.
6.2 Create New Fields
This following steps describe how to create a new field in the LANSA
Repository:
6.2.1 Step 1. Choose Your Method
6.2.2 Step 2. Add/Modify the Field's Definitions
6.2.3 Step 3. Add/Modify Field Features
6.2.1 Step 1. Choose Your Method
1. Start from Main System Menu.

PppSYSMENU Main System Menu

Enter number of function or place cursor on same line and press Enter.

3 1. Use a process
2. Submit a process to batch
3. Field control menu
4. File control menu
5. Process control menu
6. Housekeeping menu
7. Display submitted jobs - workstation
8. Display submitted jobs - user
9. Display workstation message queue
10. Exit from LANSA

F1=Help F3=Exit F12=Cancel F14=Messages

2. Select the Field Control menu option. The Field Control Menu screen is
displayed.

PppDICMENU Field Control Menu

Enter number of function or place cursor on same line and press Enter.

1 1. Create new field definitions
2. Review or change field definitions
3. Review or change field multilingual attributes
4. Review, change or create field validation checks
5. Review, change or create field HELP text
 6. Print field definitions
7. Create new system variable definitions
8. Review or change system variable definitions
9. Create new multilingual variables
10. Review or change multilingual variables
11. Create or re-create a field reference file
12. Exit from LANSA

F1=Help F3=Exit F12=Cancel F14=Messages

3. From the Field Control Menu, select the Create new field definitions option.
The Create Field Copy Options screen is displayed.
DC@P100101 Create Field Copy Options



To create this new field by
copying an existing field specify details below:

Either copy field which exists in the LANSA data dictionary
Or copy field from file in lib *LIBL





Otherwise press ENTER to proceed without copying an existing field





F1=Help F3=Exit F4=Prompt F12=Cancel F14=Messages

4. Enter either:
a) the name of the field to be copied. This field's definition will be copied to
the new field. You will then be given the option of copying to the new
field all this field's help text and multilingual definitions, and either
selecting or copying all of this field's validation rules and triggers.
b) the name of a non-LANSA field to be copied, the file and library in
which it will be found.
or
c) leave blank and press Enter. The Add Data Dictionary Field screen will
be displayed for you to enter the new field's definitions.
Note: Virtual fields must be created manually.
Go to 6.2.2 Step 2. Add/Modify the Field's Definitions.
6.2.2 Step 2. Add/Modify the Field's Definitions
When entering these details, keep in mind that you are setting a "corporate"
definition of the field. This is particularly important when defining descriptions,
column headings, labels, attributes or edit details. Try to forget the image of this
field as it will appear on a screen or report for a specific application.

DC@P100102 Add Data Dictionary Field

Field name : ______
Type (A,P,S) / Keybd shift : _ / _
Length / total digits : ___
Number of decimal positions : _
Reference field : __________ +

Description ( ENG ) : _____________________________________
Label ( ENG ) : ______________
Column headings ( ENG ) : _________________
_________________
____________________
Output attributes list : _____________________________________
Input attributes list : __ _________________________________
Edit code / Edit word : _ / ________________________
Default value : _______________________
Optional alias name : ______________________________
System field : _____
Prompting process/function : __________ / _______ +
Initial public access : NORMAL (ALL, NORMAL, NONE)

F1=Help F3=Exit F12=Cancel F14=Messages

When adding a new field, some default values will be displayed on this screen.
These default values are defined in the Field and File Defaults described in the
LANSA for i User Guide.
Field Name, Type, Length
Ideally, field names should not be longer than 6 characters (due to RPG
restrictions) and must have no embedded blanks. The first character must be an
alpha character and the use of # (hash) or @ (at) symbols is not recommended.
Refer to the notes on Optional Alias Name if you have names longer than 6
characters.
Alphanumeric fields should be used whenever possible. Fields can be Type A
(alphanumeric), S (signed) or P (packed).
The length of alpha fields (Type A) must be in the range 1 to 256. The length of
signed or packed fields (Types S or P) may be in the range 1 to 30, however, be
aware that the length of numeric fields varies between platforms. If the field is
used across platforms (e.g. Windows), fields with more than 15 digits may result
in an error or an incorrect result.
Packed decimal fields should always be an odd length.
Reference Field
Enter the name of the field to which you wish to link this field. Using this
reference field option saves you time when you are defining fields which have
factors in common. Such fields could be dates, locations, product categories and
so on. The field entered here must already exist.
Reference fields are described in more detail later in this chapter.
Description
Descriptions should make use of both upper and lower case characters. Avoid
making descriptions too long.
If the description is left blank, the field name will be inserted.
Label
Labels can be used to display the field's name on screens and reports, so it
should always be specified, preferably using upper and lower case characters.
If the label is left blank, the first 15 characters of the description will be used
instead. If the description has less than 15 character, then the remaining
positions of the label will be filled with the label fill character (usually dots)
defined in the LANSA system data area DC@A01.
Column headings
Make your column headings precise and not significantly wider than the field
itself. Use upper and lower case characters. Column headings can be underlined
as indicated in data area DC@A01.
Try to fit your column headings into only one or two lines to avoid wasting
space on screens and reports.
If the column headings are left blank, the first 20 characters of the field name
will be inserted in the first column heading line.
Output and Input Attributes
If output or input attributes are left blank, they will default to the input or output
attributes as defined in the LANSA system data area DC@A01. Separate
definitions exist for numeric and alpha fields.
The system default attributes should be correct for most fields.
Edit code / Edit word
The edit code is used to re-format your data before it is returned to your
application. Using LANSA/Server, you can also return the edit code itself, so
that your client program can reformat the data based on the code. Some edit
codes are:
Y for any form of 6 digit date.
4 for numeric fields that will never be negative.
M for numeric fields that may be negative.
Refer to the IBM manual Data Description Specifications, keyword EDTCDE,
for a full list of Edit Codes.
Default Value
The default value can be a system variable such as *DATE, an alphanumeric
literal in single quotes, such as 'LIFE COVER' or a numeric literal such as
1.345. If you don't enter a default value, blanks are assumed for an
alphanumeric field (Type A) and zeros if the field is defined as numeric (Type P
or S).
Optional Alias Name
This name must be unique. This name is used primarily for COBOL and PL/1
applications when field names longer than 6 characters are required.
System Field
YES, prevents anyone from deleting this field from the Repository. System
fields may be copied when creating a new partition.
NO, allows the field to be deleted from the Repository (provided it is not
included in a file definition, of course.)
Prompting Process/Function
Refer to the LANSA for i User Guide for details of this option.
Initial Public Access
Initial public access specifies the access other users are to be given to the field.
NORMAL allows other users to add, change and delete records but not modify
the file's definition.
ALL allows other users to add, change and delete records as well as modify or
delete the file's definition.
NONE prevents other users any access to records in this file.
Refer to Detailed Display of a Field Definition in the LANSA for i User Guide
for complete details on adding or amending the field details.
Go to 6.2.3 Step 3. Add/Modify Field Features.
6.2.3 Step 3. Add/Modify Field Features
After you have entered the field's details on the Add Data Dictionary Field
screen:
if you are copying from another LANSA field, you will be asked whether
you wish to copy all the validations, error messages, etc.
if you are manually creating this field, you will be returned to the Add Data
Dictionary Field screen to add your next field.
Once you have created your new field, press F12 to return to the Field Control
Menu to select the options to add to your new field.
You should ensure, as appropriate for each field, that:
Proper descriptions, defaults, labels, headings, stamping attributes, etc. have
been specified.
System variables for defaults have been used where possible.
Field level validations have been specified.
Messages for validations are correct.
Triggers have been defined, if necessary.
Virtual fields have been created, where applicable.
Multilingual characters have been reviewed, if applicable.
6.3 Modify Field Definitions
The same steps are followed to find your field and amend it, regardless of how
it was created.
1. Start from the Main System Menu.

PppSYSMENU Main System Menu

Enter number of function or place cursor on same line and press Enter.

3 1. Use a process
2. Submit a process to batch
3. Field control menu
4. File control menu
5. Process control menu
6. Housekeeping menu
7. Display submitted jobs - workstation
8. Display submitted jobs - user
9. Display workstation message queue
10. Exit from LANSA

F1=Help F3=Exit F12=Cancel F14=Messages

2. Select the Field Control menu option. This menu displays all the Repository's
field options.

PppDICMENU Field Control Menu

Enter number of function or place cursor on same line and press Enter.

2 1. Create new field definitions
2. Review or change field definitions
3. Review or change field multilingual attributes
 4. Review, change or create field validation checks
5. Review, change or create field HELP text
6. Print field definitions
7. Create new system variable definitions
8. Review or change system variable definitions
9. Create new multilingual variables
10. Review or change multilingual variables
11. Create or re-create a field reference file
12. Exit from LANSA

F1=Help F3=Exit F12=Cancel F14=Messages

3. To modify a field's definition, select the Review or change field definitions

option and press Enter. The Select Field to Work screen is displayed so that
you can nominate the field you wish to change.

SELFIELD Select Field to Work with

Enter full or partial name of the data dictionary field(s) to be
Worked with or leave blank to select from all fields
in dictionary . . . __________



F1=Help F3=Exit F12=Cancel F14=Messages

4. Press Enter after specifying either:

the name of field you wish to work with
part of the name, to obtain a list of the fields with names which
generically match the characters entered
 leave the name blank to obtain a list of all fields.
5. If you did not specify an actual field name, the screen is returned with a list
of fields as shown in this example using the partial field name DEM:

SELFIELD Select Field to Work with

Enter full or partial name of the data dictionary field(s) to be
Worked with or leave blank to select from all fields
in dictionary . . . DEM

Sel Field Description Type Len Dec
_ DEMAD1 Address line 1 A 25
_ DEMAD2 Address line 2 A 25
_ DEMAD3 Address line 3 A 25
_ DEMCAT Product category A 10
_ DEMCSC Cost center A 3
_ DEMCUS Customer number A 6
_ DEMDDS Division name in full A 30
_ DEMDIV Division number A 2
_ DEMDUE Date order due P 6
X DEMENT Borrower Type A 1
_ DEMNAC Name code A 6
_ DEMNAM Name A 25

F1=Help F3=Exit F12=Cancel F14=Messages

6. Place a non blank character next to the field name required and press Enter.
The Change Data Dictionary Field screen is displayed for the field you have
selected, in this case DEMENT. Any existing details are displayed:

DC@P100102 Change Data Dictionary Field

Field name : DEMENT
 Type (A,P,S) / Keybd shift : A / _
Length / total digits : 1
Number of decimal positions : _
Reference field : __________

Description ( ENG ) : Borrower Type
Label ( ENG ) : Borrower Type
Column headings ( ENG ) : Borrower
Type
____________________
Output attributes list : _____________________________________
Input attributes list : FE
Edit code / Edit word : _ / ________________________
Default value : 'S'
Optional alias name : ______________________________
System field : NO
Prompting process/function : __________ / _______
Initial public access : NORMAL (ALL, NORMAL, NONE)

F1=Help F3=Exit F12=Cancel F14=Messages F21=Change F22=Delete

These entries are the same as on the Add Data Dictionary Field screen. Refer to
the Add Data Dictionary Field screen in 6.2 Create New Fields, for notes about
this screen's entries.
The underlined areas indicate the details that can be changed.
Once you are satisfied that your field definitions are complete, you should add
or review the field's options, described in 6.4 Add or Modify Field Options.
6.4 Add or Modify Field Options
Review each of the field options on the Field Control Menu and add to each
field as appropriate.

PppDICMENU Field Control Menu

Enter number of function or place cursor on same line and press Enter

1. Create new field definitions
2. Review or change field definitions
3. Review or change field multilingual attributes
4. Review, change or create field validation checks
5. Review, change or create field HELP text
6. Print field definitions
7. Create new system variable definitions
8. Review or change system variable definitions
9. Create new multilingual variables
10. Review or change multilingual variables
11. Create or re-create a field reference file
12. Exit from LANSA

F1=Help F3=Exit F12=Cancel F14=Messages

Select the option required and press Enter. Choose the field you wish to work
with using the Select Field to Work with screen.
A description of some of the Field Control Menu items is included in the
following:
6.4.1 Field Validation Rules and Triggers
6.4.2 Help Text
6.4.3 Virtual Fields
6.4.4 Reference Fields.
For further details, refer to Fields in the LANSA for i User Guide.
Depending on the changes you make to a field, you may need to re-
generate the I/O module by "making the file operational". A list of
changes which require the I/O module to be regenerated is given in
What is an I/O Module? in this guide.
6.4.1 Field Validation Rules and Triggers
The Repository allows you to define validations and business rules at field and
file level. If multiple validation are required, each can have its own error
message. Using LANSA's validations, rules and triggers, application code
significantly reduces application code and future maintenance.
This is a brief list of the types of rules you can use:
Range of values to check a field against a range of values, such as: is the
applicant's age between 17 and 66? There are 20 ranges available for each
field.
List of values to check a field against a list, for example, M or F for male or
female.
Table/file lookup is used to check a field against a value in a file or table.
For instance, is the product number in the product master file?
Evaluate an expression allows a series of conditions to be evaluated. For
example, is item weight less than (item volume * 10.643)? The expression
can be up to 395 characters in length.
Call a program allows you to use a LANSA function or 3GL programs. For
instance, is the premium within the range for the factors supplied?
Validate a Date will check that a date is in the correct format and/or range.
For example, is the Delivery Date in format DDMMYY and within 45 days?
Each error condition should have its own error message. The error message will
only be displayed when the actual error occurs.
Triggers can be used to initiate an action, but only when the specified conditions
occur. While triggers are file based, they can use field conditions to determine if
an action is required. For example, to initiate the production of a delivery note,
but only when a new item is added to an order and if the customer's credit limit
is not exceeded. On a change of order, a different process altogether could be
triggered.
The sequence of the validations is important, so before attempting to use them
make sure that you read Field Rules/Triggers in Fields in the LANSA for i User
Guide.
6.4.2 Help Text
Field level Help text (i.e. based on the cursor location) should be input for all
fields. Separate help text can be recorded for users and developers.
For users, it provides quick and easy access to information.
For developers, notes can recorded to provide continuity between current
and future applications.
Even though LANSA can generate its own help text, it is strongly recommended
that you record help text which is pertinent to your environment. Automatically
generated help text can be suppressed.
When help text is recorded in the Repository:
it can be changed at any time without any recompiling
all message handling, from the HELP key to the display in an overlaid
window, is handled automatically by LANSA
messages will be displayed in the correct language for multilingual
applications
LANSA's documentation facility will include both user and developer
messages, to create technical and user guides.
A user only sees the user help text, but when developers are using the system,
both user and developer help text is displayed.
Help text can be copied from another field or it can be manually entered. A
standard HELP text form should be set up and used as the basis for all field
level HELP text. Use of attributes and $$ substitution variables can vastly
reduce the amount of keying required to input a field's HELP text.
Refer to the Field Help Text in the LANSA for i User Guide for more details.
Note: While LANSA provides automatic message handling routines, you also
have the facilities to develop your own routines to manage messages.
6.4.3 Virtual Fields
Virtual fields allow you to significantly reduce your application code by
centralizing the manipulation of data that is repeated in many applications.
A virtual field does not physically exist in the file. If you were to display the
contents of the file, you would not see the virtual fields. To a program, whether
a client or IBM i program, the field appears to be part of the file, however, the
value is derived when the record is input or output from the file. With virtual
fields, you could:
use fields CENTURY, YEAR, MONTH, DAY to create a single virtual field
called DATE.
store a date in YYMMDD format but retrieve and display it as MMDDYY
or DDMMYY.
derive AGE from the BIRTH DATE.
In each case, code is removed from the application. Maintenance is only
required in one place. A calculation is always the same, regardless of where it is
used.
A virtual field must be defined in the Repository and may have field and file
level validations associated with it. Validation rules for the fields used in
defining the virtual field are still enforced.
Virtual fields can be used like any other Repository field, except that:
they cannot be used outside of LANSA. Virtual fields are made possible
using LANSA's I/O module.
they cannot be used as keys in a file.
For more information, refer to Virtual Fields the LANSA for i User Guide.
6.4.4 Reference Fields
Reference fields save development time by allowing validations & error
messages, help text, triggers and multilingual definitions to be copied from the
field being referenced. Once copied from the reference field, they may be
modified to suit the new field's specific requirements.
Using a reference field is similar to using the copy facility when creating a new
field, except that the link to the reference field remains. Subsequent changes to a
reference field automatically cause these changes to be made to the fields that
reference it.
A change needs only to be made to the reference field, if the change is required
to the:
Type
Length
Decimal positions
Default value
Edit code
Edit word
Input and output attributes.
Reference fields are commonly used for dates.
Most applications have dates: Start Date, Birth Date, Application Date, Closing
Date, Delivery Date and so on. If all the dates reference a field called DATE,
then the specific validations and error messages relating to the date can be
copied from the DATE field. If all the dates are to be within, say, 60 days of the
current date except Birth Date, then you create, for Birth Date, the specific
range validations required. Should the date field change in size, such as the YY
of the year to YYYY, then only the DATE field needs to be changed. (Naturally,
report and screen changes resulting from such a change need to be handled in
the traditional manner.)
A reference field cannot be deleted while there are fields still referencing it.
However, for additional security, reference fields should be defined as System
Fields. System Fields cannot be deleted. (The System field option is on the
Create/Change Data Dictionary screen). To delete a System Field, you must first
change this option to NO.
Before any development is commenced, and particularly if you are extending a
non-LANSA application, consideration should be given to all reference fields
likely to be required, to ensure that they provide the maximum benefit to the
application's developers.
7. Moving LANSA Objects between LANSA Systems and
Partitions
How are objects moved from one partition to another, or from one system to
another?
How do you move a group of fields in the data dictionary, but not the whole
dictionary?
What happens to the validations or field help text?
How do you move a LANSA file definition and it's associated objects?
Moving objects in an integrated development environment is more than a simple
copy of files and programs from A to B. You must not only consider the "copy
from", but also the "copy to". In LANSA, you move objects using the
"import/export" facility.
To understand the import/export facility, review the following:
7.1 Basic Objects in LANSA
7.2 What is the Export/Import Facility?
7.3 How does Export/Import Work?


7.1 Basic Objects in LANSA
In LANSA, objects can be categorized into two groups:
LANSA software objects.
LANSA Repository objects.
LANSA Software Objects
These are the objects which make up the LANSA software. These are the
programs which allow you to build and maintain the Repository. For example,
the program which allows you to define a field definition or compile a file.
These objects are stored in the LANSA system's program library (e.g.
DC@PGMLIB).
Repository Objects
These are the objects which you create within LANSA. The definition of these
objects is stored in the LANSA system's data library and the actual generated
objects are stored in the partition library.
Repository objects include the following:
definitions of fields, files, functions and processes
compiled objects, including I/O modules, processes and functions (if
developed using LANSA)
files and their data.
As new applications are developed, these Repository objects will be added,
changed and deleted. Controlling these basic objects is a critical part of the
System Administrator's responsibilities.
These classes of objects require different backup strategies and these are
described in Backup and Recovery in this guide.
7.2 What is the Export/Import Facility?
The export and import facilities in LANSA enable the definitions of fields, files
or processes to be "exported" from one LANSA partition and then "imported"
into another LANSA partition.
Objects that are not part of the LANSA system, such as user defined data areas
or message files, may also be exported and imported via these facilities.
The export and import operations may involve LANSA partitions resident on
the same machine either within the same LANSA system or different LANSA
systems, or resident on different machines.
The most common example of moving objects is when an application is
modified. The changed objects will be moved from a development partition into
a production partition. The partitions might be in the same system or might be in
different systems. The systems might be on the same machine or different
machines.
The importance of the "export" and "import" facilities is that they allow LANSA
applications to operate effectively in multiple environments on the same
computer, or on multiple computers within an organization.
7.3 How does Export/Import Work?
In order to copy objects from one partition/system to another, you need to create
a list of objects to copy. The objects in the list can then be saved to some storage
medium. Once saved, you can restore the objects at their new destination.
The steps in LANSA terms are:
1. Sign on to the LANSA partition containing the objects to be copied.
2. Create an "export list" of objects to be copied from this partition.
3. Request LANSA to export items on the list onto a magnetic tape or a save
file.
4. Sign on to the LANSA partition/machine into which the objects are to be
copied (or use the Housekeeping option to change to the partition into which
the objects are to be copied).
5. Request LANSA to "import" the saved objects.
Please note that the partition from which you do each of these steps is VERY
important.
The export and import facilities are powerful save and restore commands. They
take into account the integrated nature of the LANSA development
environment. For example, when you export a file definition, the physical file
and all its associated items such as the logical files, virtual field definitions,
access routes, batch control definitions, validations, help text etc. are all
exported. Similarly, when a field is exported, its field level validations and help
text are also exported.
On systems that have QCCSID (Coded Character Set Identifier) and QLANGID
(Language) parameters set to non-standard (not default) values, imported data
will be converted according to the default CCSID of the QLANGID parameter
and not the QCCSID of the system.
For example:
QCCSID = 00500 (international code page)
QLANGID = CAT (Catalan)
The default CCSID for CAT (Catalan) is 00284. Therefore, all data will be
converted to code page 284 and not code page 500, the QCCID value.
For more details about Import/Export refer to:
Initialization Imports in the Installing LANSA on IBM i Guide
and
Exporting and Importing in the LANSA for i User Guide.
8. Transferring Complete LANSA Systems between IBM i
Systems
If you intend to move the entire contents of one IBM i machine
(source) to another IBM i machine (target) you will only need to apply
for a new LANSA license code before using your LANSA system on
the target machine. See item 1 in Make a Plan of what you intend to
do

These instructions are intended for a one time, large scale transfer of a LANSA
system between IBM i systems.
You will use these steps to move your LANSA system when you move your
development and/or execution environment between systems.
These transfer steps are recommended:
Make a Plan of what you intend to do
8.1 Transfer the LANSA System to the same type of IBM i
Make a Plan of what you intend to do
On the Source Machine
Make a note of:
the EPCs, partitions and settings to use when installing LANSA on the target
machine.
whether you are using Visual LANSA Framework. (If so, you will need to
copy the IBM i-side definitions found in the IFS root
VF_System_Definition_<program library>*.*.)
the partition security officers.
the partition libraries and LANSA libraries.
the Web Port, and Listener Port, if applicable.
If you have any doubts about any part of your plan, do not hesitate to contact
your product vendor for advice.
On the Target Machine
1. From your product vendor, obtain LANSA license code(s) for all the LANSA
products that you intend to use on this machine.
Your product vendor will need to know the system's CPU serial number,
 model number and processor features. To display the required information,
use the WRKSYSVAL command and select option 5 on the Work System
Values screen and note:
System serial number (QSRLNBR)
System model number (QMODEL)
Processor Feature (QPRCFEAT).
2. Check if the user profiles have been created on this machine. If not, make a
note that this must be done.
8.1 Transfer the LANSA System to the same type of IBM i
Before you start, ensure the configuration of the target IBM i is
complete.
Refer to the IBM i Information Centre
http://publib.boulder.ibm.com/iseries if you require further
information.

Have you installed all the pre-requisite software required by the

LANSA features you will be installing?
For example, RPG or C compilers, HTTP server, XML Toolkit, PASE
objects, etc.

Do not start the transfer until the software updating is finished.

On the Source Machine

1. Export all the partitions. You can, for example, add DEM to a Save file
DEMPART, SYS to SYSPART and so on.
If you are using Visual LANSA Framework, copy the IBM i-side definitions
found in the IFS root VF_System_Definition_<program library>*.*.
On the Target Machine
1. Install a new LANSA system with the same names, partitions and settings
(such as the Web Port and Listener port) as recorded on the source machine.
2. Apply any relevant EPCs. You can install the latest version if desired, but
you must apply any available EPCs (if any) for that version.
3. Create all the required user profiles if they haven't already been created.
4. Make sure the partition libraries and security officer are the same as in the
source system. If not, change them to be same as the source system.
5. Import each Save file to each partition.
If you are using Visual LANSA Framework you will need the IBM i-side
definitions to go into the IFS root VF_System_Definition_<program
library>*.*.
6. Apply the new license codes.
7. Test your LANSA system to ensure that it works as expected.
9. Reorganizing the LANSA Internal Database
LANSA stores information about fields, files, functions and processes in a
number of database files. These internal LANSA files reside in the LANSA
system "data" library, normally called DC@DTALIB.
For example, when a LANSA file is defined, while the database file and its
associated I/O Module are created in the partition data library, the details used
by LANSA to define the file (fields in the file, validations, logical files, access
routes, help text) are stored in several LANSA internal database files in the
system data library. When a file maintained by another system is made known to
LANSA, its definition is stored in these same internal files.
In order to improve the performance of any IBM i application, the database files
should be "reorganized" on a regular basis to:
free up disk space.
improve the performance of both LANSA and client applications due to the
improved access to the data on the IBM i.
For further details, refer to Re-Organizing the LANSA Internal Database in the
LANSA for i User Guide.
10. Backup and Recovery
The back up of the LANSA objects should be integrated with your
regular IBM i system backups. Failure to do this will be very costly,
should a system failure occur.

Backing up your LANSA objects is a vital task which should be carried out on a
regular basis. If you are already using LANSA for i and you intend on using
LANSA for the Web, then you will need to change your backup procedures.
Different LANSA object types need different backup strategies.
In LANSA, there are:
LANSA Software ObjectsThese are the objects which make up the LANSA
software. They include the programs which allow you to build and maintain
the Repository, such as the program which allows you to define a field
definition or compile a file. Most of these objects are stored in the LANSA
system's program library. Some object are stored in the LANSA
communications library.
LANSA Repository Objects
Repository objects fall into these subclasses:
LANSA Repository Definitions of fields, files, functions and processes.
These objects are stored in the LANSA system's Data Library (i.e. your
program source).
LANSA Executable Objects such as I/O modules, functions and
processes (i.e. your executable programs created using LANSA).
Application data files.
If LANSA COMLIB=QGPL, there are also:
LANSA Software and Repository Objects NOT stored in the LANSA
Program Library or the LANSA Data Library
If you are using a dedicated com library that is not QGPL, then you do not
have to save QGPL. If you are using QGPL, it is recommended that you
convert QGPL to a dedicated LANSA com library. This setup is documented
and it is the preferred library for LANSA. If QGPL is still being used as the
com library, some LANSA objects are stored in the QGPL library. Which
objects you have in the QGPL library will depend on the LANSA products
you have installed and the version of the LANSA products you have
installed. Some of them are named DC* (e.g. Host Monitor for Visual
 LANSA), GU*, LC* (for LANSA/Server), LX* (for LANSA SuperServer)
and W3* (for LANSA for the Web). Backup the files at the frequency
recommended for LANSA Repository Definitions and the other objects at
the frequency recommended for LANSA Software Objects.
LANSA for the Web - Special Backup Considerations
Additional objects need to be considered for backup. Note that the library
specified in the Web administration as the working library contains no
permanent objects.
Web Server Software and Configurations
This is software such as ICS. A backup of this software and your
configurations needs to be carried out at a similar frequency to the
LANSA Software Objects.
IFS Objects
These are the images that are shipped with LANSA for the Web, plus
additional images that you have created for your applications. They should
be backed up at the frequency recommended for the LANSA Repository
Definitions.
CGI Script Library
This library should be backed up at the same frequency as the LANSA
Software Objects.
Multi-tier Deployment
If you have implemented a multi-tier deployment of LANSA for the Web,
you will have installed on your Web server machine some software
objects in an administration library and in QGPL. The original of these
objects is included with the LANSA objects on your Data Server machine
and can be recovered from there if required. However, the changes you
have made to settings and configurations in the administration library and
in QGPL need to be backed up so they can be recovered if needed.
For more information about Backing up your files, refer to:
10.1 Recommended Minimum Backup Frequencies
10.2 A Simple Restore Strategy.
10.1 Recommended Minimum Backup Frequencies
Note: As some LANSA objects may be held in the QGPL library, this library
needs to be included in your backup strategy. For more details, refer to the
Installing LANSA on IBM i Guide.
These are the minimum recommended backup frequencies for each Object
Type:
Object Type Development Production
LANSA Communications Objects (supplied as After install After
DC@COMLIB). or upgrade install or
In the event of a total systems failure, if you have otherwise upgrade
not backed up this library, you could re-install Monthly otherwise
LANSA and all PCs and EPCs that you have Monthly
added since the original installation.
LANSA Software Objects (supplied as After install After
DC@PGMLIB). or upgrade install or
In the event of a total systems failure, if you have otherwise upgrade
not backed up either library, you could re-install Monthly otherwise
LANSA and all PCs and EPCs that you have Monthly
added since the original installation.
LANSA Repository Definitions (supplied as Weekly with Weekly
DC@DTALIB). changes with
The frequency with which you backup these saved daily changes
libraries will depend on the level of development saved daily
activity. You may choose to backup the
production system more often if you are
frequently updating help text, for example. If you
move a new application into production, you
should back it up immediately.
LANSA Executable Objects Weekly Monthly
The frequency with which you backup these
libraries will depend on the current level of
activity. In the event of system failure, these
executable objects could be recreated from the
 LANSA Repository definitions, provided, of
course, that the definitions have been backed up
at the recommended frequencies.

LANSA Application Data Files

The application data files, in which end users add, change and delete records,
should be backed up daily as a regular housekeeping task as part of your site's
security strategy. Failure to backup these files daily could lead to serious or total
loss of your business data.
10.2 A Simple Restore Strategy
In the event of total system failure, if you have followed the suggested backup
frequencies, you will be able to restore LANSA for i by following these steps:
1. Re-establish all existing user profiles and authorities before starting these
restore steps.
2. Re-establish the system from the latest LANSA Software Object backup.
If you have selectively backed up your QGPL library, contact your product
vendor if you are unsure which LANSA objects to restore from the QGPL
backup.
3. If any new upgrades or EPCs were applied to LANSA for i after this backup
was taken, reload or reapply them.
If necessary, these can be (re)supplied by your product vendor.
4. Overlay the latest weekly and daily backups available.
5. Recompile any user defined programs which were created or amended since
the latest backup.
6. LANSA for i is ready to use. At worst, one full day's work may be lost, but
only if you have taken backups at the recommended frequency.

11. LANSA Education
Proper training is essential to the success of any enterprise. Getting the right
training with LANSA is essential to your success with the product. The LANSA
Training Program allows you to get the right training for the right people at the
right time.
The overall objectives of the LANSA Training Program are to:
Improve general knowledge of development concepts and the LANSA
product's capabilities.
Provide practical experience emphasizing the approach to system
development with LANSA, i.e. how you should build, not just how to build
with LANSA.
Create a defined learning path to provide training tailored to the needs of
each member of a development team.
LANSA offers both self study Tutorials and instructor-based training. The
Tutorials provide a simple introduction to developing applications with LANSA
and they are not a replacement for the instructor-based training workshops in the
LANSA Training Program. Tutorials are shipped with the LANSA
documentation.
We strongly recommend instructor-based training for your staff. Instructors can
provide immediate answers to questions and provide valuable insights into
using the product. Contact your local LANSA vendor for details and schedules
of their instructor-based training courses or review the courses offered via the
Services menu at the LANSA web site.
Training is not compulsory; however, proper training will allow you to get the
best return on your investment in LANSA.