1. LDA III.

Unisys has created a Windows based PC LAN development environment (LDA) that will become, in time, the development environment of choice for nearly all LINC users. This multi-user environment supports the development and maintenance of LINC systems including graphic screen design and logic development. LINC sites are beginning to recognize the advantages of the workstation development environment using LDA. Establishing a good LDA development practice can greatly enhance development productivity. LDA also provides multi-user run time testing on the PC workstation.

2. Platform Independence.

Unisys has released the LINC products in the Open UNIX and NT environments. LINC is available on the U6000 Series of UNIX platforms as well as on Sequent, Sun, HP and IBM RS6000 platforms. Running production LINC information systems on UNIX is a viable solution.

Stumbling Blocks.

To take advantage of these new opportunities, several challenges must be overcome on two fronts:

1. Moving the data requires unloading the data into 'flat' files on the original host, transferring the files to the target platform and loading the files into the run-time system.

2. Moving the LINC specifications requires extracting the specifications into a case file (not LCOPY) on the original host, transferring the case file to the target platform and loading the case file into LINC/LDA.

Removing the Stumbling Blocks.

To ensure the most cost effective and successful means to migrate both specifications and data, Information Exchange Group, Inc. (IEG) has focused its experience on automating this process returning results quickly, reducing labor costs, lowering risks, and assisting management through accurate information. IEG has products and services to help established LINC users make the transition and to help new LDA users maximize benefits of these new environments. The IEG products and services, known as Information Migration, address movement to both Open UNIX, NT and LDA PC LAN development and test platforms.

Moving the Data.

Information Migration consists of both a methodology and the required processes that allow data movement between LINC applications on A-Series, 2200 Series, UNIX, NT, or the LDA workstation. The differences in data representation between various platforms can make this a rather challenging process.

IEG's Information Migration process generates LINC report programs, specifically for the user's application, to unload data from the existing repositories -- one report per structure -- in a platform independent format. Existing file transfer utilities can safely move this data format between platforms. Once resident on the new platform, the same reports load the data into the LINC application database. Specific features of the LINC reports produced by IEG's Information Migration process are:

• Parameter file control
  The user is prompted with a request for desired functions in the absence of a parameter file. The presence of the parameter file allows the migration routine to run in batch mode without operator intervention.

• Option to "LOAD" or "UNLOAD"
  Each generated report has the ability to both LOAD and UNLOAD the data.

• Common data record layout
  The extracted data is in a generic character format that allows file transfer utilities to move data between architectures without losing numeric signs and decimal points.

• Ordinate validation (optional)
  Whenever an ordinate is a data item in a related record, generated logic performs a validation against the parent record. It is important that data is loaded in an order establishing static information first, followed by dynamic transaction information.

• Date field validation (optional)
  Fields defined as edit date are verified using the LINC DATE.CONVERT construct to ensure dates are valid.

• Required Field validation (optional)
  Data items defined as required fields are tested for zeros and spaces.

• Numeric field validation (optional)
  Data items defined as numeric are tested for numeric values.

• Area for user modifications
  Each report contains a section for user logic. It is often helpful to the developer to select specific business information. User logic can be added to the UNLOAD or LOAD procedures to narrow the data to selected department numbers, product numbers, or customers. Using LDA to modify the report, the developer can easily and quickly add this logic giving immediate results.

• Documentation for each report
  Each report contains documentation explaining the features and operations of the report including the names of the flat data files and error logs from validation logic.

Moving the Specifications.

Another area that is addressed by the Information Migration suite of products and services is the movement of LINC specifications. While the actual movement of the LINC specifications to the new environment is a simple process, getting those specifications to generate cleanly or run efficiently might not be so simple. There are several well-documented reasons why this is true. Reserved words are different between platforms. DETERMINE and LOOK.UP verbs may behave differently, and less efficiently, with an Oracle database.

IEG has tools to simplify this process (called IM software). These tools help automate changes to the specifications. For example, the IM software replaces reserved words, replaces control sequence highlights in screens and logic, and helps update the DETERMINE and LOOK.UP verbs to be more efficient. These tasks, which could take long periods of time if done manually, are reduced to much shorter and more manageable intervals. The IM software:

• Applies changes automatically, consistently, and completely throughout the specification
• Documents all changes in hard copy arranged by GLG, ISPEC, and Report
• Documents all changes inside the affected logic (except as noted below).

Hex Control Codes

The transport of the CASE file can introduce problems to the migration process. Data communication null characters (hex 00) can cause the CASE extract file to encounter load errors on the target platform or corrupt the LINC/LDA repository. The IM software:

• Fixes and reports nulls (Hex 00) in the CASE extract file
• Reports embedded T-27 terminal highlighting codes on screens (invoking the LINC equivalent highlight attributes where possible)
• Replaces T-27 terminal highlight codes in logic by reassembling literals thereby making the hex codes maintainable in LDA.
• Removes trailing spaces from the CASE file records
• Removes blank records

Target Platform Reserved Words

Each LINC platform has its set of reserved words. A specification that edits, generates and compiles cleanly on one platform might not on another. Newer versions of LINC allow the user to nominate potential target hosts and LINC will check new names against reserved words of the target hosts. Unfortunately, existing names must be allowed to survive. LDA analyzes names very conservatively, and will reject them even when qualified; therefore, LDA is a good test filter for reserved word usage. The IM software:

• Replaces reserved words in screen and database items as well as logic with words of the user's choice
• Documents the changes arranged by GLG, ISPEC, and Report
• Note: These changes are not documented in affected logic.

Data Item Conflicts

Various naming conflicts must be resolved before moving a specification to LDA, NT or UNIX. Most of these situations have resulted from features being implemented in host LINC releases. As some features are added, existing conditions may not have been detected. The situation can exist where a data item is defined differently than the dictionary edit attributes. Another conflict can be caused from naming items using more than 10 characters. Host LINC also allowed a data item to be named the same as a report or other LINC objects.

IEG uses the same process used in fixing reserved words described above.

DT; FROM, DT; BACK, DT; LAST, LU; FROM and LU; BACK Commands

Even though the "Group" construct was added to optimize performance in an Oracle environment, it greatly simplifies coding for DTs and LUs. The IM software:

• Converts the logic to use DT; GROUP and LU; GROUP where performance on the target platform may be at risk and where "standard" coding conventions have been used
• Proposes a "best guess" otherwise
• Marks the construct in the model for quick accessing (through Logic Status) where human intervention is required.

The IM process interrogates the LDL code following the DT/LU statement. DO.WHEN statements are examined for matching PROFILE keys along with a BREAK or JUMP.TO, END format. This defines "standard" code.

When IM is unable to detect "standard" DW, BK, END coding, the best suggestion is generated and inserted as a comment line.

External Interface Changes

External interfaces are mostly platform dependent. For example, CALLs to system libraries and STARTs of jobs will have to change to comply with the new run time environment. Each library and job will have to be evaluated for the value that it must provide on the new platform and must be rewritten or skipped. LDA run time does not support external AUTOs (HUB, USER, NOFORM). The IM software:

• Builds logic around all instances of CALLs, STARTs and external AUTOs using a CASE of GLB.MACHINE.

File Naming Conventions

The naming format for external files varies for each platform. All RAS, RTN and SETT statements which could contain an external file name literal are cross-referenced. All RTN and RAS are changed to SETT statements. The SETT is surrounded with a BEGIN.CASE on GLB.MACHINE with tests for each platform. Since we do not know the location to place the files on various platforms, a Global Logic routine is provided to centralize manipulation of file names and locations. The IM software:

• Builds logic around all instances of SETT DATANAME using a CASE of GLB.MACHINE.
• Moves a literal to DATANAME to avoid platform COBOL compilation errors.

Limits Tests

The various run time platforms have different limitations on the database schema. The IM software:

• Documents Profiles having a key length greater than 240 characters
• Documents ISPECs containing more than 247 data elements
• Documents multiple items with lengths greater than 2000 characters.

Note: These are Oracle limitations under LINC 16.2.

LDA Compliance

Numeric Sub-Items

Moving spaces to an SD group item will put zeros in subordinate numeric items on EBCDIC platforms. On ASCII platforms, the numeric items will receive 20s rather than zeros. The IM software:

• Replaces "MV; GLB.SPACES <sd-group>" with "INITIALIZE; <sd-group>".

LDA Data Dictionary

LDA more strictly enforces uses of dictionary items and will not load any conflicts into the LDA repository. For those who have begun using the dictionary later in the development cycle, these conflicts could be numerous. For those who want to begin using the dictionary, the task of promoting items to the dictionary can be very time consuming, especially if there are conflicts to resolve. The IM software:

• Carries any existing dictionary item attributes to LDA
• Promotes any data base items which have been used consistently
• Demotes any data items which have been used inconsistently
• Reports data items that have been used inconsistently and their locations.

Keywords

Many mature specifications used keywords for standard Component ordinates. Now, the preferred mechanism is to use multi-ordinate memo Components. LDA does not support the maintenance of keywords even though the information is in the CASE extract file. The IM software:

• Builds the keyword as individual data items on the screen.
• Changes the keyword item to an output item or a local SD keeping the original name.
• Inserts logic to move data from the screen data item parts to the new output item.
• Adds logic to move data to the screens parts whenever the output item is used as the target of a logic statement.

This process does have a risk associated with it's implementation. The LINC logic to perform BAC, REC, FIR, LAS, or NEX is lost. Changing the Ordinate to Usage Output will deimplement this logic. If this is critical, then a Multi-Ordinate Memo Component should be considered.

Large CASE Models

Sometimes working with large CASE extract files (128 MB) can be a difficult process. There may be occasions when access to the CASE extract file is required using special diagnostic tools (such as WEDIF) having even lower file size limits. The IM software can: can:

• Divide the CASE extract file into parts 15 to 20 MB each
• Reassemble the parts to a whole for archival purposes
• Note: no documentation is produced for this utility function.

• Remove unnecessary record types
• Separate business rule information into a CASE model of its own (see 'LDA Business Rules' below)
• Separate Teach/Help screens into a CASE model of its own.

LDA Environment

LDA Model Organizer

Host LINC maintains no conceptual information in the specifications akin to the Functional Areas and Activities of LDA. Thus, LDA loads all objects as "orphans" in the Business Segment. There is no model organization to aid development and further maintenance. The IM software:

• Carries any existing Functional Areas and Activities to LDA
• Builds a Functional Area for subsystems
• Builds Activities for each subsystem
• Builds a Functional Area for report generate groups
• Builds Activities for each report generate group
• Builds a Functional Area for general organization
• Builds Activities for
  • ISPECs which define the database
  • ISPECs having screens
  • Profiles
  • Reports
• Populates the Activities with the appropriate objects (note that an object can exist in multiple Activities).

LDA Cross Reference

LDA does not provide a full cross reference. Although LDA's Design Analysis function shows how to improve design, there is no way to determine the effort required. There is no mechanism to discover the impact of a proposed change to a data item or structure. The IM software:

• Builds supporting information for cross reference
• Provides context sensitive inquiry into the cross reference.

LDA Business Rules

LDA allows business rule documentation to reside in word processor compatible files. There are no longer limits as to size of business rules. Documentors can work with tools with which they are comfortable, and the business rules can be printed according to site standards that may use advanced word processing features. The IM software:

• Moves business rule text and teach screens to a text file.

GUI Screen Painting

LDA can maintain graphical screen designs (GUI) and export them to Power Client or be used as a basis for web enabling an application with ActiveLINC. In today's applications, Windows users expect features such as check boxes, radio buttons, command buttons, list boxes, and graphic pictures. It can be very time consuming to convert yesterday's character oriented "dumb terminal" screen to a graphical screen. While it is necessary to write LINC logic to use some of these features (such as populating a list box), much of the basic "face-lifting" requires no logic changes.

As a IM option, IEG will include initial GUI screens and IEG's Information Builder (IB) which:

• Allows the user to choose basic GUI standards
• Produces basic graphical screens for all ISPECs and GLGs having screen images
  • Hide the "LINC header"
  • Apply consistent colors and fonts to display, input, and inquiry fields
  • Convert the "Maint" field to command buttons.
• Applies new GUI attributes to specific lines on all screens throughout the entire specification.
• Creates GUI attributes for fields which have Dictionary Validation Logic.
• Applies new GUI attributes to a screen data item throughout the entire specification.
• Generates Active Server Pages and DHTML to support deploying the application to an internet via ActiveLINC.

See WeBuildForms.com for more information.

Targeting the Future.

While it is easier to move to a new platform with LINC than any other development environment, it is easy to grossly underestimate the required effort unless you have done it before. IEG has the experience and tools that automate the mundane letting you concentrate on the more profound aspects of migration. IEG's Information Migration can save untold amounts of time, money and frustration in moving your LINC information systems to a new platform.