CorVision

The birth of CorVision CorVision can be traced back to 1972 when Lou Santoro and Mike Lowery created INFORM for the newly formed time-sharing company Standard Information Systems (SIS). INFORM contained some of CorVisions basic utility commands such as SORT, REPORT, LIST and CONSOLIDATE. Some of the first users of INFORM were New England Telephone, Polaroid and Temple Barker & Sloan. By 1972 SIS had offices in Los Angeles, Garden Grove, Minneapolis, Chicago, Boston, New York City, District of Columbia, Charlotte, Raleigh, Atlanta and Phoenix. Establishing CorVision Between 1976 and 1977 Ken Levitt and Dick Berthold of SIS ported INFORM from the CDC-3600 to the PDP-11/70 under IAS. They called this new tool INFORM-11. Cortex was founded in 1978 by Sherm Uchill, Craig Hill, Mike Lowery, and Dick Berthold to market INFORM-11. INFORM-11 was first used to deliver a 20-user order entry system at Eddie Bauer, and to deliver an insurance processing system for Consolidated Group Trust. Between 1981 and 1982 Cortex received significant investment from A. B. Dick. Using this new investment, Cortex ported INFORM to Digital Equipment Corporation's new VAX/VMS, adding compiled executables. INFORM-11 was promoted by both Cortex and Digital as a pioneering rapid application development system. In 1984 Jim Warner encapsulated INFORM in a repository-based development tool and called it Application Factory. INFORM's PROCESS procedural language became known as BUILDER within Application Factory. In 1986 the name of Application Factory was dropped in favor of the name CorVision. CorVision's heyday Between 1986 and 1989 CorVision experienced its heyday. It quickly became known as a robust and capable tool for rapidly building significant multi-user applications. The addition of relational database support attracted major accounts. Cortex quickly became an international company. In 1992, CorVision Version 5 was released with Query and support for Unix. Query allowed read-only access by users and developers to a systems database backend. Where this seemed a desirable facility, allowing users to create "use once then throw away" reports without calling on developers this had a nasty habit of causing performance issues. Users often did not understand the database structure and could send large queries to the processing queues causing system-wide issues. In 1993 Cortex started supported vesting to Digital's new 64-bit Alpha line. In 1994, International Software Group Co. Ltd. (ISG) purchased Cortex. The beginning of the end for CorVision As early as 1987, Cortex recognized the growth in the popularity of the IBM PC, supporting wikt:diagrammatic editing of menus and data relationships in CorVision. In 1993 a client-server version was released, but not widely adopted. In 1997 ISG's work on CorVision-10 which was to herald the rebirth of CorVision onto the IBM PC platform stopped. CorVision-10 was proving very difficult to port and ISG finally refused to spend any more money on the now-dated system. 1994 saw the last innovative CorVision release: V5.11. The extra-fee Y2K release, V5.12.2, marked the end of development. CorVision as a legacy system CorVision still exists in a handful of companies that have not yet found the time or money to upgrade their existing mainframe systems. As CorVision runs on the VMS environment it is very stable but the search for CorVision developers and contractors to support these ageing systems is a problem. Since around 1999, companies have started appearing offering conversion tools to convert BUILDER code to compiled Visual Basic and Java. In 2005 CorVision guru Michael Lowery, now president of Order Processing Technologies, attempted to revive the CorVision franchise with CV2VB, a process to convert CorVision applications into .NET applications using a SQL server. CV2VB is OPT's third generation CorVision conversion and replacement modeler/code generator. It is in commercial service at former CorVision clients. Information is available at the CV2VB website. ==Application development==

A brief explanation of application development using CorVison. Application parameters The first step in developing an application with CorVision is to fill in the parameters which control the miscellaneous aspects concerning application-wide functions. The parameters fall into five groupings as follows: • Heading, Title and Menu Information for the application. • Development parameters which affect the CorVision working environment. • Run-time parameters which affect run-time execution of the application (including Batch & Print Queue control). • Application-wide navigation options. • Application-wide standard menu items. Usually the default values for these parameters are satisfactory. CorVision however allows for these setting to be changed at any time during development. The parameters file (WP) is accessed at runtime so the latest setting are always used. Status Screen CorVision keeps the information behind the Status Screen up-to-date so that it indicates the current state of the development process. The left hand side indicates specification tasks that need doing. The right hand side indicates generation tasks that need doing. Changes or Additions to Specification and what they cause changes to. Dictionary, Datasets and Keys • Generate *.CRE, build Links Dictionary, Datasets, Keys • Screens, Reports, Dataviews Screens, reports • Generate *.SCR, *.RPT, *.JOB Menus • Generate *.DO Field Search CorVision provides a useful feature called Field Search. Field Search allows you to investigate and analyze the use of fields in different aspects of the application. This allows developers to assess the impact of changes before they are made. To provide complete specification details in hardcopy form, CorVision has the Run Reports option. Over 80 different types of report can be produced. Component Specification Reports (CSRs), as they are known, can also be produced for tentative, unreferenced and unresolved items. Procedures and processes The key to CorVision is PROCEDURES. The procedures in CorVision eventually become Executable Images (.EDO's). Three types of procedures are: ;Screen Procedures: Used for data entry and updating, can be accessed from a menu and is navigatable. A Procedure of this type consists of the Menu selection and any key screens and data screen. These are generated and compiled together. You can look upon the screen procedure as the MAIN procedure which is called MAIN by default in CorVision. ;Jobstream / Report Procedures:Presentation of data as a report. A Procedure of this type consists usually of one step to produce a report. It is generated and compiled separately from the screen procedure. ;Custom Procedure: Hand coded procedures in BUILDER. These procedures can perform any function that the BUILDER code will allow. A Procedure of this type is written entirely in BUILDER, the CorVision 4GL. It too is generated and compiled separately from the other two types. It is not essentially true to consider a procedure as a program. In fact, a procedure is a set of instructions (BUILDER Commands) which build a program. A program in BUILDER is actually called a Process not a program. A Procedure therefore is a set of BUILDER commands which instruct BUILDER to build a process and save this in the program library as a compiled file with a .SAV extension. Data independence CorVision keeps the data structure files separate if they are to be manipulated by BUILDER. BUILDER keeps a structure file and a key structure file for each dataset used by the application. When a process is compiled, the data structures are "bound" to the process at that time thus "binding" of data structures takes place at the precise moment the process is compiled. Because the structure and key structure files are kept separate, the dataset definitions can be altered during development. This is a major strength of CorVision allowing for a prototyping environment where both code and data structures can be changed throughout development then brought together at compile time. The structure and key structure files are loaded before the process is compiled. This is done by the load file. BUILDER makes the assumption that the data structures are already loaded when it compiles a process. It is at this point that the compilation "binds" the data structures to the code. Creating a procedure • Add / Change the procedure specification • (Progressively) Construct the application components • Menus • Screens • Reports • Custom Code • (Progressively) Generate the compilable files • Compile the procedure After generating the procedure The following files are created: • .DEF :Define fields used within the procedure. • .DFS :Define (.DEF) files used within the procedure. • .DO :Generated BUILDER for controlling the running / compiling of the procedure. • .IOS : the procedure. • .LOA :Generated BUILDER for controlling the loading of all required datasets used by the procedure. • .SCS :List of all screens used in the procedure The following files can also be added: • .DCL :DIGITAL command language file. • Define specific CorVision logic. • Define any other processing before the procedure is run. The following files are created after compiling: • VAX 32 bit • .SAV • .EDO • ALPHA 64 bit • _TV.SAV (after vesting) • _TV.HIF (after vesting) • _TV.EDO (after vesting) ==References==