LINC 4GL

LINC was originally developed as a short-cut (or template) by two programmers to reproduce and automate the production of computer applications for different companies, that had similar requirements and specifications. The requirements were similar, because the companies followed a common, generic, business model.

That is, these businesses dealt with "commodities", or "parts", or "suppliers", or "customers" (named "components" in LINC terminology). These were "manufactured", or "assembled", or "purchased", or "sold" (actions termed "events" in LINC terminology).

These components and events were the "interface specifications" or "ispecs" and contained the database definitions, screen designs, and business rules of the application system.

LIRC (Logic and Information Report Compiler) was part of LINC and was developed to allow the programmer to produce reports (e.g. "purchase orders", "invoices", "credit notes", "consignment notes", "bills of sale"). The information in these reports were accessed by using various user-defined views of these components and events called "profiles".

Because reports run as a separate task (as a separate thread of execution) they could also be written to run as a background process; that is, it could put itself to sleep for a period of time or until woken, to perform some processing, then put itself to sleep again.

Part of the reason for the introduction of this new terminology was to make the system easier for programmers. It isolated them from a lot of the underlying technology. (Similarly, different names were intentionally used for control structures: DO.WHEN rather than IF or LOOP, and LOOK.UP or DETERMINE rather than READ, with the OPEN and CLOSE statements generated automatically.)

What allowed LINC to make programmers much more efficient and the application systems they produced easier to read and maintain, and differentiated it from being simply yet another third generation high level language, was LINC's assumption, use of, and total reliance on all of the facilities available, and packaged, with the Burroughs computer for which it was written: operating system, job control language, COBOL programming language, database management system, network definition, user terminal, etc. (See also "history" below.)

From version 11, its character changed. Where LINC (and LIRC) specifications had previously been held in source-code files, they were now held in a database (designed and developed using the LINC 4GL) and subject to rigorous automatic validation. The new LINC-based system in which specifications were stored was named LINC interactive or LINC Development Environment (LDE).

Extensive reliance on terminal "screen painting" (i.e. "mocking"-up a CRT data-entry screen) was used to assist system definition. e.g. to define a component's database attributes (name, length, alpha(numeric), validation rules, etc., and for defining report layouts).

In the early 1990s, a new PC-based tool for developing LINC specifications was released, the LINC Development Assistant (LDA). LDA was written in a mixture of Smalltalk and C++ rather than the LINC 4GL (the latter of which was not intended to run on a personal computer). From version 17, it was intended that all development be done with LDA.

Now LINC is known as Unisys Enterprise Application Environment (EAE) and can generate COBOL code for Burroughs & Sperry mainframes, Microsoft Windows, and various Unix and Linux platforms. It will also generate GUI front-end clients in

• Java
• Visual Basic 6 clients
• Active Server Pages
• Web services for Microsoft IIS
• ASP.NET
• VB.NET

in addition to compiling generated code and deploying databases to correspond with the specification. Databases supported include Burroughs DMSII, Sperry RDMS, Oracle database and Microsoft SQL Server.

Recent Update:

Unisys is replacing EAE with Unisys Agile Business Suite (AB Suite). The LDL language is promoted to LDL+, with new object-oriented features. The Development environment makes use of the Microsoft Visual Studio IDE. The Model Driven approach is extended with a UML based Class Diagram integrated with all the source code of the solution, in such a way that a round trip update is achieved. Changes in the Business Rules can result in changes in the UML representation and vice versa.

AB Suite 4.0 makes use of Visual Studio 2012 and integrates with Team Foundation Server 2012.

AB Suite generates to either a .NET environment or a ClearPath MCP environment.

With AB Suite a developer has to write less code than in a traditional C# or Java environment.

• It provides an intuitive and easy-to-understand interface to the Burroughs DMS and COBOL programming.
• As it has been modernised to support different platforms, it facilitates migration between platforms and databases.
• By confining a specification in a database, the entire design can be kept in a single design and development environment.
• Once generated, the code is absolutely consistent with its design specification.
  • A client interface is always consistent with a system generated at the same time.
  • The system's database access code is always consistent with the system's database tables.

Principally, LINC fails to compete against myriad turnkey systems readily available from many other sources (especially IBM). The cost of purchasing and customising an existing product (e.g. the Hogan retail banking system) is perceived as less expensive/risk than using LINC to create, from scratch, an entire business system with all its rules.

Other weaknesses arise mostly from its dependence and basis on Burroughs DMS and COBOL, which differ greatly from other computing platforms.

• People entering the industry or from a Unix / Windows background may struggle to adjust to this different paradigm.
• Functionality can be limited by the need to support multiple platforms. You can't use optimal Oracle structures or queries if the mainframe platforms don't support them.

• Information Exchange Group, provider of utilities for assisting development with LINC, http://www.ieg-inc.com/