iSeries Introduction

Introduction to LANSA for iSeries

  • 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 March 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 iSeries 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 iSeries 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 I5/OS 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 operational" after changes to these items: | Files do not need to be "made operational" after changes to these items:
Access Routes with Predetermined Join Fields | Access Routes without Predetermined 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 I5/OS 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 iSeries 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 i5/OS 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.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 iSeries 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.5 LANSA Help

The Help key (F1) has a number of uses within LANSA for iSeries. 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 iSeries 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 iSeries 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 system 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.

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 iSeries 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
  • i5/OS 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 i5/OS user profile which 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 i5/OS 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 i5/OS 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 : XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

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 iSeries 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 iSeries 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.


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 iSeries 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 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 iSeries 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 i5/OS 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 i5/OS 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 iSeries 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.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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 iSeries 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.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 iSeries 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 iSeries 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 iSeries 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.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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 iSeries 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 Objects
    These 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 DC@COMLIB). In the event of a total systems failure, if you have not backed up this library, you could re-install LANSA and all PCs and EPCs that you have added since the original installation. | After install or upgrade otherwise Monthly | After install or upgrade otherwise Monthly
LANSA Software Objects (supplied as DC@PGMLIB). In the event of a total systems failure, if you have not backed up either library, you could re-install LANSA and all PCs and EPCs that you have added since the original installation. | After install or upgrade otherwise Monthly | After install or upgrade otherwise Monthly
LANSA Repository Definitions (supplied as DC@DTALIB). The frequency with which you backup these libraries will depend on the level of development 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. | Weekly with changes saved daily | Weekly with changes saved daily
LANSA Executable Objects 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. | Weekly | Monthly

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 iSeries 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 iSeries 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 iSeries 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.


Disclaimer

While every effort has been made to ensure that the information in the LANSA documentation is accurate. In no event shall LANSA be liable for any damages arising from its use.

LANSA MAKES NO WARRANTIES, EXPRESSED OR IMPLIED.

Copyright and trademark information

© LANSA. "LANSA" is a trade name and registered trademark of LANSA in the United States of America, Australia, the United Kingdom and other countries. All rights reserved.

The following are some companies which require attribution:

Java and all Java-based trademarks are trademarks of Sun Microsystems, Inc. in the United States, other countries, or both. Microsoft, Windows, .NET and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both.

Other company, product, and service names may be trademarks or service marks of others.

This material may contain other proprietary notices and copyright information, the terms of which must be observed and followed.