WO1990004227A1

WO1990004227A1 - Software manufacturing system

Info

Publication number: WO1990004227A1
Application number: PCT/US1989/004539
Authority: WO
Inventors: Donald. M. Magyari, Jr.; John J. Masker; Gonzalo E. Correa; John R. Horn
Original assignee: Expressway, Inc.
Priority date: 1988-10-12
Filing date: 1989-10-10
Publication date: 1990-04-19
Also published as: CA2000447A1; AU4504689A

Abstract

A method and apparatus for manufacturing software is disclosed. Portions of an edit file (2) are labeled with markers (10). A program model (3) is created which associates each marker with a usage class, a selection class, and a question or other user interface (5). The usage class and selection class define the manner in which input from the user will be treated, so as to generate compilable source code (7, 100).

Description

SOFTWARE MANUFACTURING SYSTEM Cross Reference to a Microfiche Appendix

Microfiche Appendix 1 is included herewith and includes 167 fiche, comprising approximately 4613 frames. Said Appendix is incorporated herein by reference. BACKGROUND OF THE INVENTION

Field of the Invention

The present invention relates to the field of computer programming. In particular, the present invention provides a greatly improved method and apparatus for automated development, management, and maintenance of computer programs.

Description of Related Art

In the development of computer programs (otherwise referred to herein as "software") the common practice has been for a user with a particular need to express the need to a computer programmer. The computer programmer then writes a series of computer commands which direct a computer to perform a function which satisfies this need. The commands may be written in any one of a wide variety of languages including COBOL, BASIC, FORTRAN, PASCAL, "C", or one of many other computer programming languages of the type readily known to those in the computer programming industry.

Frequently the programmer finds that the needs of a particular user are similar to the needs of other users with whom he has dealt in the past. Therefore, the programmer is able to refer to programs he/she has written in the past, extract pieces of the program which would be useful to the new user, insert any necessary "custom" code, and produce a new computer program (this technique commonly referred to as the "cut-and-paste" technique). The cut and paste technique has dramatic disadvantages which are almost immediately apparent. Initially, the technique assumes that the programmer is aware of and has access to the code he/she and other in his/her organization have developed. This is frequently not the case, and as a consequence the programmer develops custom code to perform functions for which code has already been developed. Furthermore, extracts from the prior work are often found to be incompatible or inefficient when applied to the remainder of the code developed by the programmer. Perhaps most importantly, programmer time is wasted because the programmer is spending significant amounts of time finding, relating, changing, and assembling known building blocks. This time could be spent more productively in developing new code which meets new needs of business. Reducing this wasted time is a primary goal of the invention described herein.

Maintenance of software is also a major concern. If, for example, an organization develops software which performs a similar function for a variety of software package clients, even a small change causes substantial re-coding of the software for each client. This results in an undesirable duplication of effort at best. At worst, a small change may impact each version of the software differently, requiring a significant effort for each client. Furthermore, even a small change within a program may result in dramatic effects on other portion of the program. Tracing these interrelationships is frequently a very time-consuming and, therefore, expensive process.

Several systems had been utilized which are directed towards solving the above problems. For example, the use of subroutines relieves the problems to a degree. A subroutine is a series of commands which perform a specified function and is appended to the code of the primary program (and compiled therewith) the subroutine is "called" one or more times to perform a function. The use of subroutines, however, suffers from many of the above mentioned problems. For example, all programmers may not be aware of the existence of a particular subroutine, the subroutine may be incompatible with the main portion of a new program, and programmer time is wasted "pasting" together available functions. "Macros" perform a similar function, but may be integrated into the body of the main program.

The use of "COPYLIB" is also in common use. A COPYLIB "pulls" in a set of source code which performs a function or contains a needed set of code that is not compiled with the main program. Again program compatability and the like are major problems. In addition, the many relationships between the old code and to new code to be developed are not easily traceable.

From the above it is seen that an improved and automated method/apparatus for automatic production of software programs having similar functions is needed. In particular, it would be desirable to provide a method/apparatus for producing software in which end users may develop software programs without a knowledge of the language used within the program and in which relationships within a set of code can be effectively managed and traced. It is further desirable to devise a method and apparatus for producing fully reusable software code, which can readily be maintained. It is still further desirable to accomplish the above with a set of tools that are language and system independent. SUMMARY OF THE INVENTION

The present invention provides a method/apparatus for synthesizing, managing, and maintaining changes to computer programs which contain lines of code that perform similar or related functions. In particular, the present invention provides a system for producing and maintaining code in a fashion that is easily modified and which is straightforward to maintain.

In general, the method described herein permits a programmer to develop re-usable code. An edit or text file of the type commonly known to those of skill in the art is created which contains "markers" and "labels" at portions of the program which are modifiable and/or optional. A program model is then created which provides a variety of functions. The program model may, for example, associate each label with a user interface. The user interface may be, for example, a series of questions. The program model also associates each label with one or more "usage" classes which may relate to one or more of the markers and a "selection" class. In general, these classes define the manner in which the input of the user in response to the interface will be treated. The class may provide, for example, that the response" of the user to a question will be substituted directly for a specified label within the edit file. The class may alternatively provide, for example, that a label within the edit file will be replaced with a programatic entity such as a data element, a structure record's internal name, or any other entity/attribute of a value given to the label that is stored in a dictionary.

Accordingly, in one embodiment the method comprises the steps of providing source code having portions thereof identified as modifiable with an identifier; creating a program model, the program model associating at least a portion of the modifiable portion with a user interface for input as well as an input attribute, the input attribute defining a manner of inserting code based in the input; prompting for input with the interface, and; based on the input and the input attribute, modifying the source code to create a custom compilable computer program. The input attribute may be, for example a usage class, a selection class, or the like. The usage class and selection class may define when the input of a user is to be accepted and will determine now the input is to be treated when it is input.

The modifying step may include the sub-steps of inserting a copylib module, inserting a data structure, a screen, or a function and may further include the step of adding portions which are also modifiable.

Apparatus for carrying out the above method is also described.

DESCRIPTION OF THE DRAWINGS FIG. 1 provides a broad overview of the use of the invention described herein.

FIG. 2 provides a summary of the process for developing program models.

FIG. 3 depicts a completed model.

FIG. 4 provides a schematic overview of the manner in which the program functions.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

The method/apparatus described herein provides an automated method of manufacturing software. The method/apparatus is fully system and language independent.

The description herein describes embodiments directed towards COBOL programs in the Tandem environment, both of which are well known to those of reasonable skill in the art. It is to be understood however, that such embodiments are only intended to be illustrative. The method/apparatus described herein could easily be applied by one of reasonable skill in the art to other environments (IBM, etc.) and other languages (BASIC, FORTRAN, PASCAL, etc.) based upon this description. The method/apparatus could also be applied to word processing programs, used as a text editor and the like.

The computer programs to which the method/apparatus described herein could be applied perform a wide variety of functions. For example, the computer programs could perform accounting functions, scientific functions, data storage and manipulation functions, or the like. Merely to serve as one example, one possible function that could be performed by such a program is to input billing information and output bills at an approproiate time based on the input.

This description is divided into 4 sections, which are as follows: (1) Expression Program Function, (2) Building Program Models, (3) Generating Programs, and (4) Glossary. Section (2) includes sub-sections relating to (a) the creation of data structures, (b) the creation of screens, and (c) the development of COPYLIB modules. The glossary provides descriptions/definitions of terms that are used throughout this description.

FIG. 1 provides a brief summary of the of the invention described herein. In general, a programmer or similar user 1 will create an edit file 2 and program model 3 the view Expression program. The edit file 2 contains lines having one or more identifiers or labels 4 which indicate elective and/or modifiable lines in the edit file. For each label, the program model 3 will define how and in what order the elective and/or modifiable parts of the edit file 2 should be modified (via input attributes such as an associated usage class, selection class, and the like) and may associate the label with a question 5 as well as a script for presenting the questions. It should be noted that the invention herein is described by way of example with "questions" as a user interface. It should be recognized, however, that the invention could be used with other user interfaces for prompting a user for input. For example, the program could be designed such that a program presents a screen to the end user which contained "blanks" to be completed by the user. Other methods of interfacing with the user for input would be apparent to those of reasonable skill in the art.

After creating the edit file and program model, the user 6, who may or may not be a programmer and need not even be familiar with the program language, is asked a series of questions by the model. Based on responses to the questions, the user 6 may create a compilable application program 7. While the invention is illustrated with respect to an application program the invention could be applied to any executable object.

The user 6 may be a person who has no knowledge of the programming language or may be another or the same programmer. The word "user" is used herein to indicate a person who could be creating the edit file, the model, or creating programs from a model.

The above functions are carried out in an appropriately programmed CPU 8 which is preferably a digital computer of the type well known to those of skill in the art.

(1) Expression Program Function

The computer program listing (©Copyright, 1988, Expressway, Inc.) for the invention described herein is included herewith (in "TAL", a language well known to those of reasonable skill in the art) pursuant to 37 C.F.R. 1.96 in the form of microfiche and is incorporated herein by reference. The program is initiated in the file named logon-service.

In general, the attached program including the "generator" (after a log-on procedure and the like) will begin by scanning the edit file (otherwise referred to herein as the program model source) for markers. The marker is used to determine when action is to be taken by the generator. Labels are are also provided and are associated with a "table" or tables which provides control information.

The generator then modifies a line in the edit file in a manner depending upon a "usage" attribute. This usage attribute determines the discrete action to be performed against the value or attribute of the value from a dictionary. Conditional action may also be taken into consideration if they have been so defined, all labels in the edit file are evaluated for this particular marker before moving to the next line in the program model. The process is then repeated.

The generator catalogs all label values used and the relationships when a program is generated.

The program enables a programmer to change a program model or copylib module label script without modification to the Expression generator, and to migrate and reload all program scripts. Further, a change in script control may be made without affecting any models or the Expression program. Specifically marker control can be maintained with varying labels and the like without modification to the generator as recompiling of the Expression program. Additional action "verbs" may be added dynamically to the generator for use in any or all models. Because of the

separation of usages, scripts, conditionals, markers, and source, the flexibility of building blocks is provided without affecting individual entities.

As shown in Fig. 4, the attached program includes a program generator 100, which is used then to generate programs 102 from the model. The program generator create the program by first scanning a source edit file 104 for an SDL marker 106. When an SDL marker is encountered, the program generator reads a model control file 108 to obtain associated line labels and usage class values. The program generator then uses the line labels to locate read a program script file 110 which includes a question, response line label activation value (selection class), and replacement values. The activation and replacement values together with the line label usage class values direct the program generator logic to modify and/or include final program elements into the compilable source program 102. The source program may include data structures 112, screens 114, and copylibs 116. When the final source program is compiled, all elective or modifiable process elements are traded into "using" and where used" catalogs for later use.

Each program model which is created has a private script file 110 whose records contains field for: - The line label - Selection class - Script question sequence number - Script question text - Script question response (Line label activation and replacement value.)

Usage class values are stored in the model control file 108 along with the SDL## marker and any associated line labels. Each model has a private control file whose records contain fields for: - The SDL## marker

- Line labels

- Usage class values for line labels Model control and script file records are configured through the use of the AD.07 model configuration service, and are associated with a unique skeleton source file. When a program is to be defined a duplicate copy of the model script file is created. This copy, referred to as the program script file, is private to the program being defined. Script question response line, label activation, and replacement values are inserted into program script file records during the use of the AD.07 program definition service.

Script records for any parameterized copylib modules are also included into the program script file. This serves to provide a permanent scripts response record of each program defined through the use of a model.

(2) Building Program ModeIs

This section describes how to design and build program models from which to define and generate any number of application programs that have the same, or similar, characteristics and functionality using the above described software. Expression applications that are PATHWAY applications are used by way of example. The use of SCOBOL and COBOL in Tandem's PATHWAY environment is used herein, is readily known to those of reasonable skill in the programming art, and is not further described.

The components of any given computer program can be placed in one of three categories:

- Fixed, non-modifiable - These components must be included in every program that is written in a particular language (e.g., the division/section headers that enforce the architectural layout of COBOL/SCOBOL programs) and can be different in each program.

- Fixed, modifiable - Components in this category must be included at least once in every program, but may have a different value in each program (e.g., the program ID in the COBOL language).

- Elective, modifiable - These are components that may be required by some programs, but not others. The user determines which component to use for any individual program, and how many of each, based on the task(s) to be performed. The components in this category include:

- Structure of the main procedure

- Data Structures

- Table Structures (Lists)

- Inter-Process Message Structures

- Linkage Structures

- Screens

- Files

- Input/Output Operations

- Functions assigned to function keys - Algorithms

- Procedures (e.g., validation procedures)

For practical purposes, most of the components in the "elective, modifiable" category are either structures that will hold some type of data or the logic that will be applied to the processing of that data.

The program model is used to:

- Provide the generic framework for defining any number of application programs that have the same, or similar, characteristics and functionality. This framework consists of the fixed, non-modifiable components required by a particular programming language, as well as other components that can be expected to stay the same for all the programs generated off a particular model.

- Identify the fixed, modifiable components that are required by all programs of a particular type, but may have a different value for some programs.

The PROGRAM-ID, SOURCE-COMPUTER, and OBJECT- COMPUTER paragraphs required by SCOBOL programs are examples of fixed, modifiable program components.

- Identify the elective, modifiable components that may or may not be included in a particular program.

The definitions of "fixed, non-modifiable", "fixed, modifiable", and "elective, modifiable" may be clarified to reflect the fact that different items may be made optional or modifiable in different program models. For instance, the source- computer and object- computer are, as defined above, fixed modifiable, but some users will usually want them to be T-16's, for example, so from the point of view of those models they can be made fixed, non-modifiable. As another example, if the user is going to build a number of requestors from a model, and the user is going to use the same IPC prefix for all of them, instead of making it elective, modifiable, the user might want to make it fixed, non- modifiable from the point of view of that model.

From the model:

- Base element definitions can be used by any number of files and structures;

- Files and structures can be used by any number of screens;

- Screens, files, structures, and copylib modules can be used by any number of program models to generate any number of custom application programs.

Every program model starts out as a source edit file, written in the language in which subsequent programs will be generated. In the examples decribed herein, this will be SCOBOL for requestors and, COBOL for servers.

The process of converting a source file to a program model is called "parameterizing". This is a two-phase process: 1. identifying and marking the optional and/or modifiable parts of the source program with line labels or a similar identifier, and

2. telling the Expression program about those parts, so it will let the end user a) select optional parts to include in the generated source program, and b) provide specific values for the modifiable parts, at program definition/generation time.

As shown in Figure 2, the user first identifies the parts of the source file that are optional and/or modifiable. The user takes the parts that are elective ("control edit lines" or copylibs) out of the source file, and marks the spot with a "source line ID". The user will put the removed parts into a control file later, along with the source line ID so Expression will know where to re- insert the part which was taken out. (A control file is a file internal to Expression that stores information about how to turn the model's source skeleton program into a compilable source program). The user leaves the parts that are required, but should be modifiable, in the source file ("source edit lines") and marks them also with a source line ID. The user will be left with a skeleton source file which contains all the fixed, non-modifiable components, probably some fixed, modifiable components, and probably some elective, modifiable ones.

The user marks all modifiable parts of the source, whether left in the skeleton or taken out of the skeleton and put in the control file, with "line labels" or a similar identifier. Each line label will be replaced when a program is generated by an end user, based on an entry so as to result in a compilable source program.

in the second phase of the parameterization process, the user: - puts the source line ID's and line labels of fixed, modifiable source lines in the model's control file;

- enters short components (typically one line, but always less than 3) which were removed from the skeleton along with their source line ID's and line labels, into the model's control file as control edit lines;

- writes each component of substantial length as a copylib section and introduces it to

Expression as a reusable copylib module.

Information is put in the control file that will cause either, a COPY statement or the whole copylib section to be put into the source file at program generation time.

Copylibs can themselves be parameterized through the same process described herein, - assigns most of the line labels a question or similar user interface for input (such as a screen) which will be presented to the user at program definition time. For some line labels the user's answer will become the line label's value. For some line labels, the value is known in advance, or the line label only acts as a flag, so there is no need to assign it a question.

- assigns the questions (which are collectively called the script) a sequence so that they will be presented to the user in a particular order.

- defines how the end user's response will be treated via input attributes which may be, for example, a usage class and a selection class. These input attributes identify the manner in which the file is modified based on user input and may be, for example, a selection class will determine when the line label will be, which "actuated", i.e., when it will be installed in the source code or a usage class which will determine what will happen when the line label has become activated.

(See the discussion of line labels, selection class, and usage class in the glossary).

More specifically, after the program model is generated, the user will initially name a program that is to be generated, specify the program model to be used, and the Expression program will assign a copy of the label/script table the program. The user will also name a resulting source destination file name and an object (executable) target file name.

The user is prompted with, for example, screen or questions which are then presented to the user. The questions are answered as described by the user to build a program. Depending on positive/negative response by the user, or a value supplied by the user, script control is provided, along with a stimulus to provide the next question, along with the activation of any labels that are customatically desired by vritue of the question having been answered. If the question relates to a variable "copybook", the value of the answer may point to a specific copybook which may also have an associated script, which is then copied and bound into the initial program script.

Figure 3 illustrates the resulting program model. The model includes the source edit file 2. The source edit file contains a variety of SDL labels, indicated in Figure 3 by "X" and "Y .

Control table 10 contains, for each control key, an associated set of information which may include control information, modifiable and dump edit lines, and a usage class for each of a variety of labels (illustrated) herein with A, B, ... i) which may appear in the control key. Label/script Table 12 contains for each label A, B ... i, an associated set of information which may include control information, script control, value fields, and question text.

EXAMPLE 1

A simple model is constructed below as an example of the above process. This model demonstrates the use of source edit lines, control edit lines, which are modified and un-modified, selection classes 0 and 2, usage class 0, and demonstrates the use of the same source line ID appearing in two different places.

A listing of simple a COBOL program is shown in Table 1

This program displays "This is a sample program." on the screen. Four items will be parameterized in the program: the computer ID, the author's name, the source/object computer, and the line that generates the display. Programs could then be generated from this model which have different values for each of these items. A copy of the program is made and, using an editor of the type readily known in the art, is amended to appear as shown in Table 2.

There are five lines beginning with the SDL- label "SDL##". Four source line ID's are used in this program: PROGRAM IDENTIFICATION, PROGRAM AUTHOR, TYPE OF COMPUTER (which appears twice) and DISPLAY MESSAGE. Each source line ID is preceded by four lines of comments.

The first source line ID, PROGRAM IDENTIFICA¬

TION, has one line label associated with it: PROGRAM NAME. (All the source line ID's and line labels in this skeleton are in upper-case, but this is not necessary). This source line ID's edit line is a source edit line: program-id PROGRAM NAME.

The label, i.e. PROGRAM NAME, will be replaced by the exact response entered by the end user in answer to the label's associated script question.

The next source line ID has the same name as its line label: PROGRAM AUTHOR. The source line ID and the line label will not be "confused", since source line ID's only appear in lines with SDL## or SDL@@, and line labels only appear in source or control edit lines. In this case the edit line is a control edit line (notice that the following line is commented out). Expression will replace the line label with the user's response to its script question, then put the edit line into the source program immediately after the

SDL-labelled line (i.e., this is an example of a "control edit" line).

The next source line ID also has the same name as its line label: TYPE OF COMPUTER. Notice that this source line ID appears twice: once for the source computer, once for the object computer. Though the two source edit lines are different, the mechanism will work the same for both: Expression will find the line label, i.e., TYPE OF COMPUTER, in both the source edit lines, and replace it with the end users exact response to TYPE OF COMPUTER'S script question.

The last source line ID, DISPLAY MESSAGE, will place the control edit line: display "This is a sample program." into the source program. There are no line labels in it, so no changes will be made, however, the control file record will have an associated line label anyway, which must become activated, or the line will not be placed into the source file. There are four lines of comments preceding each source line ID, e.g. *---------------------------------------------------------------------------- * M/D Line Label l Usage

* D - DISPLAY MESSAGE - 00

*------------------------------------------------------------------------------------

These comment lines document the line label (s) associated with the source line ID. This is useful since the line labels are not always obvious, especially in the case of control edit lines and copylibs.

. The comments are arranged in columns. The "M/D" column tells whether the line is to be modified or "dumped" (i,e., placed into the source program); the "Line Label" column is self-explanatory; the "Usage" column tells the usage class of the line label. If there had been more than one line label for this source line ID, the information for the second label could be placed below the first label, as shown below: *------------------------------------------------------------------------------------ * M/D Line Label l Usage

* D - DISPLAY MESSAGE - 00

* D - DISPLAY MESSAGE 2 - 00

*---------------------------------------------------------------------------------------

In addition, if the edit line is a control edit line, a commented-out version of it should be placed below the SDL-labelled line for later identification. If a copylib is to be brought in, a blank line or two should be inserted.

When the skeleton is constructed, the user must make known to Expression control instructions for each of the source line ID's. First the user must register the model with Expression. Upon entering the

Model Configuration (AD.07) service, Page 1 appears as shown in Table 3. If the user wishes the model to be called SIMPLE MODEL, this is typed into the Model Name field, COBOL is typed into the Language field, and any pertinent comments are entered into the comments field.

The mode window begins on Select Model. It is rolled to Register Model and <F9> is pressed. The model will be registered and automatically selected.

If the user wants to make changes to a model that has already been registered, the user should return to the Model Configuration service, find the desired model by using the Read keys, and press <F9> with the mode window on Select Model.

The user may now enter the control instructions by striking <F2> and moving to page 2, as shown in Table 4. The user enters information relating to the source line ID's on this screen. The first source line is PROGRAM IDENTIFICATION. This name is typed into the Source Line ID field at the top. A "P" is entered into the (P)rogram ID field to signify that this source line ID applies to the program name. A "2" is entered in the Line Control Type (1 or 2) field to signify that this source line ID applies to a source edit line (control edit lines are Line Control Type 1). An "M" is entered in the Action (M)odify or (D)ump field so Expression will know that there is a line label in the edit line that it should modify. The top part of the screen then would appear as in Table 5.

The user now tells Expression what line labels to use with this source line ID. The line label is PROGRAM NAME, and its usage class is 0, so the user will fill out the next fields as shown in Table 6.

Notice there are nine such lines on this screen. A different line label may be entered on each line, so up to nine line labels may be entered per source line ID for source edit lines.

Relevant comments are entered in the Comments field. <F7> is used to insert the information and is followed by a massage that the line label has been inserted, "OK".

To correct a mistake, the correction is entered and <F14> is pressed. To correct information in the Source Line ID field, which is the primary key, it is deleted with <F12> and reinserted.

For the PROGRAM AUTHOR source line ID field, the screen is filled out as shown in Table 7.

There are only three significant differences between this source line ID definition and the last one: the (P)rogram ID field is left blank (since this is not the program identification line), the line control type is 1 (meaning control edit line), and the control edit line is written on the first of the three longest lines in the page. Notice that the line label PROGRAM AUTHOR is in the control edit line. At program generation time the line label will be replaced with its script question's response, and then the control edit line will be dumped into the generated source file. <F10> is used to enter the PROGRAM AUTHOR control information.

A different control edit line may be entered on each of the three longest lines on this screen.

They will be dumped into the source file successively. Three line labels for each control edit line may be used.

For the next source line ID, the TYPE OF COMPUTER is entered into the Source Line ID field; "2" is entered in the Line Control Type (1 or 2) field; and "M" is entered in the Action (M)odify or (D)ump field. The line label is entered with usage class 0, as above. This control record will act on both the SOURCE COMPUTER and OBJECT COMPUTER lines in the source file, as explained above.

For the last source line ID, DISPLAY MESSAGE is entered into the Source Line ID filed; a "1" is entered in the Line Control Type (1 or 2) field; and a "D" in the Action (M)odify or (D)ump field. The control edit line:

DISPLAY "THIS IS A SAMPLE PROGRAM.". is entered onto the first of the three longest lines. Even though no modifications will be made to the source line, a line label for it is needed so it will be dumped into the source file. DISPLAY MESSAGE is sufficient. This line label, with usage class 0 is entered as shown in Table 8.

When the source line ID's have been made known to Expression, it is necessary to enter information pertaining to the script. It is necessary to 1) give each line label that needs one a script question, as well as a selection class, etc. and 2) set the script sequence. These are both done on page 3 of this service. <F2> is entered to move to the next page, as shown in Table 9.

On a computer screen, the top few fields of the screen are shaded; these fields are for setting the script sequence. The lower half of the screen (shown in Table 10) is used first. The name of the first line label, PROGRAM NAME, is entered into the Line Label Name field. The user tabs to the "Required with Primary" field and a "Y" is entered. This indicates that the user will be required to answer this line label's question (if an "N" is entered, the user could skip over it, leaving the line label unactivated). In the Selection Class field a "2" is entered. This means that the line label will be replaced directly with the user's script response. On the last two lines of the page the script question is entered. The bottom part of the screen should then appear as in Table 10. <F10> is used to insert this record.

For the PROGRAM AUTHOR and TYPE OF COMPUTER labels, the entries in the fields other than Line Label Name will be the same, except that different questions will be entered. The situation is different for the DISPLAY MESSAGE line label. This line label must always be activated, so its control edit line will always be dumped. The Line Label Name is entered and given a selection class of 0, and the rest of the fields are ignored.

The script sequence is now inserted. The mode window is rolled to "Assign Script Sequence". The fields that were shaded become bright, and vice versa (except that the Line Label Name field stays bright). To set the sequence, instead of using the Insert, Update, and Delete function keys, the Assign Script Sequence and Delete Script Sequence mode windows are used. "#START#" is entered into the Primary Line Label Name field. #START# is the root primary line label, i.e., the starting point, for every model. The script sequence number for the line label is entered in the Script Sequence field (10 is a good place to start.

This allows room to insert additional numbers later). "PROGRAM NAME" is entered into the Line Label Name field. The top part of the screen should appear as in Table 11.

With the mode window on Assign Script Sequence, <F9> is pressed. Script numbers are assigned in this way for each of the line labels (always using #START# for the primary line label).

The model is now complete. The last two pages in this service allows the user to look at what has been entered and are self-explanatory. Page 4 of the service shows the line labels and associated information in list form; page 5 of the service displays the script questions as the user will see them. Example 2 A more sophisticated example relating to one construction a computer program model is provided below.

In this section, a model is built for a requestor which displays a screen to the user, accepts data from the screen, and does a send to a server which will write that data into a file. Subsections are included which describe how to produce screen and structure declarations, how to produce structure/element names, how to generate a line a specified number of times, and how to use primary and subordinate line labels.

The requestor model allows the user, at program definition time (i.e. the time at which the user supplies information from which Expression generates a compilable computer program), to choose the screen, the screen's associated structure, the error-replay structure (which is sent back from the server in case of error), the IPC-prefix, the server, and the number of function keys which the user will be able to use to send the message to the server.

The requestor model includes examples of usage classes 0, 2, 8, 9, 10, and 11; selection classes 2, 3, and 4; source edit lines; control edit lines that are generated a specified number of times; control edit lines that are generated specified number of times while a counter inside the line is incremented each time; Line Control Type 1 as it's used with declarations of Expression generated screens and structures; primary and secondary line labels; and, optional script questions. The server model includes examples of usage classes 24, 28 and 29. All of the available selection and usage classes are listed in Tables 12 and 13 respectively.

A pseudocode version of the procedure division of a program is included In Table 14 below and will be used for the example. There are seven paragraphs in the PROCEDURE DIVISION: SEND-SERVER-MAIN, SEND-SERVER-EXIT,

DO-ACCEPT, SEND-TO-SERVER, SEND-ERROR, GET-OUT, and KEY-NOT-IMPLEMENTED. SEND-SERVER-MAIN displays the screen and then loops on the DO-ACCEPT paragraph until the user presses shifted <F16>. DO-ACCEPT does one of three things: if the user presses <F1>, <F2>, or <F3>, it calls GET-OUT which sets a flag which gets the user out of the program; if the user presses anything else, it calls KEY-NOT-IMPLEMENTED which sends a relevant message to the error window at the bottom of the screen.

SEND-TO-SERVER sends the data that the user typed into the screen to the server, and then (1) if an error occurred on the send itself, it calls SEND-ERROR to display a message about it to the user; (2) if the send itself was good but an error occurred inside the server (say, an error on the data file) it displays a message about that, using error-info that came back from the server; (3) if the send was good and no errors occurred inside the server, it redisplays the data that the user typed in (which has been to the server and back), and displays "BEEN THERE AND BACK." in the error window.

The skeleton for a complete program using the above Procedure Section is shown in Table 15.

Proceeding through the skeleton from beginning to end, features of the program are noted below.

At the top of WORKING-STORAGE there are two flags and an ERROR-WINDOW. The ERROR-WINDOW is used by the last field in the screen, which is hard-coded into this model and will therefore be present regardless of which screen is chosen in program definition.

Also in WORKING-STORAGE are source line ID's where the declarations for the IPC prefix, the data- record, and the error-reply record will be sourced in. The error-reply record is the message that is sent back from the server in case of an error. The data-record is sent to the server so the server can write the data into its file, and the screen that was painted off of it is sourced in down in the SCREEN SECTION.

In DO-ACCEPT, the send of the server is determined as follows. A script question asks the user how many function keys should be implemented. If the user answers with "03", the lines: F001

F002

F003 will be generated inside the ACCEPT statement, signifying the first three function keys. Three corresponding SEND-TO-SERVER's will be generated inside the following PERFORM statement. If while running the SCOBOL program, the server will be invoked.

The comments for these two line labels have an extra line in them:

* Occurs Ascending from 1 to or Label NUMBER OF FUNCTIONS USAGE 0

The information in this line corresponds to extra information typed into the Control Definition Screen for such control edit lines.

Some of the line labels in the procedure division will be replaced with a record name; some of them will be replaced with the name of an element within a record. PATCHOM should know the name chosen for SERVER NAME after compiling he server.

The above model could use any number of

Expression-generated structures and screens to produce a particular source program. For purposes of illustration, three simple structures and one simple screen will be illustrated below. What follows are the SCOBOL declarations of the IPC prefix, the data-record, and the error-reply record that will be illustrated.

The IPC prefix, whose logical name is PREFIX is as follows:

01 PREFIX-REC.

02 REPLAY-CODE PIC 9(4) COMP.

02 MESSAGE-TYPE PIC 9(2). REPLY-CODE is used by the requestor as the required first two bytes in the REPLY part of the SEND statement. MESSAGE-TYPE is used by the requestor to tell the server which function key the user pressed.

The data-record, whose logical name is EMPLOYEE DATA is as follows:

01 EMPLOYEE -DATA -REC.

02 ID-NUM PIC 9(2).

02 FULL-NAME.

03 LAST-NAME PIC A(20).

03 FIRST-NAME PIC A(10).

03 MIDDLE -INITIAL PIC A.

02 FILLER PIC X(4). The error-reply record, whose logical name is ERROR DATE is as follows:

01 ERROR-DATA-REC.

02 ERROR-TEXT PIC X(31).

02 GUARDIAN-ERROR PIC 9(4).

02 FILE-STATUS PIC 99.

The screen, whose logical name is EMPLOYEE DATA SCREEN is as follows:

EMPLOYEE DATA SCREEN ID NUM EMPLOYEE NAME____________________

The declarations of the IPC prefix, the data record, and the error-reply record in the above model are all produced the same way, with usage 11. Taking the data record as an example, on page 2 of the Model Configuration service, the Line Control Type is 1, and the line label (NAME OF FILE 001) is usage 11, as shown in Table 16.

Usage 11 makes Expression, at program generation time, go into a data dictionary and find the name of the copylib section where Expression put the declaration for the structure when it was created using

Structure Definition. (Note that this is not the same as a copylib module. Copylib modules are declared as such in the Copylib Module Configuration service, and this is one of Expression's internal copylibs.) Expression then puts the COPY statement for it into the generated source program so that the declaration will be brought in at compile time.

The NAME OF FILE 001 line label's entry on page 3 of this service appears as shown in Table 17.

If the user wants the line label to stand for one of the structures in the data dictionary, it is necessary to use a selection class 3. Use of selection class 3, 4, or 5 requires that the user specify whether it is a screen or a structure, so it is necessary to put an "S" in the Type field. (For screens, a "V" is used.) Since the structure name is required for any programs generated from this model, a "Y" is used in the Required With Primary filed. The default for Required With Primary is "N".

In the example of setting the script sequence set further below, the screen in Table 18 will be seen.

For this example, EMPLOYEE DATA would be entered. This will cause, at program generation time, the declaration for EMPLOYEE DATA to be copied into the WORKING-STORAGE section where the DATA RECORD DECL source line ID is; and if this line label is used with some other source line ID, appropriate action will be taken there also, depending on the label's usage class.

To produce a screen declaration for the

SCREEN SECTION of the DATA DIVISION, the above steps are the same except that a usage class 20 is utilized and a "V" is placed into the Type filed of page 3 of the Model Configuration service.

Usage 8 will replace the line label with the name of the structure, (There is no usage class that will replace a line label with the name of a screen.) The IPC MESSAGE source line ID (which appears twice in the skeleton, once for the SEND and once for the REPLY) uses usage 8 for two different line labels, PREFIX and NAME OF FILE 001. The Control Definition entry for it appears as shown in Table 19.

If the SDL-labelled line and the source edit line appeared as follows:

*SDL##IPC MESSAGE

SEND PREFIX, NAME OF FILE 001 and if the user answered the labels' script questions with PREFIX and EMPLOYEE DATA, then it would result in the following:

*SDL##IPC MESSAGE

SEND PREFIX-REC, EMPLOYEE-DATA-REC

Note that labels MUST APPEAR IN THE SAME ORDER on the Control Definition Screen as they do in the edit line.

To produce the name of a particular element within a structure, usage 2 is used. For instance, the Control Definition entry for source line ID FILE STATUS is shown in Table 20. Usage 2 must be used in conjunction with selection class 4, which requires, as its script response, the name of a structure (or screen) AND the

name of an element within it. The Model Configuration page 3 entry (as related to the ERROR REPLY line label) would, therefore, appear as shown in Table 21.

At program definition time, the script question/answer would then appear as shown in Table 22.

This will cause line:

MOVE FILE STATUS TO FILE-STATUS OF ERROR-WINDOW

in the skeleton to be modified thus:

MOVE FILE-STATUS OF ERROR-DATA-REC TO FILE-STATUS OF ERROR-WINDOW As the model is set up above, the error-reply record that the user chooses must have both GUARDIAN

ERROR and FILE STATUS fields in it. If the user decided that the model should be able to handle an

error-reply record that does not have a FILE STATUS

field, the edit line is made a control edit line, and the FILE STATUS script question is made optional.

Therefore, the script question is unanswered, the line label is activated, and the control edit line will not be dumped into the source program.

To cause a control edit line to be dumped into a program a specified number of times, the Occurs fields is used on the Control Definition screen. To

make a counter inside the line be incremented with each generation of the line, Occurs and usage 9 are used.

To cause:

SEND-TO-SERVER to be dumped into the generated source program once for each function key that the user wants implemented without the counter, the entries shown in Table 23 are made into the Control Definition Screen This is a control edit line, so a "1" is placed in the Line Control Type (1 or 2) field. There are no line labels to be modified in the edit line, so a "D" is placed in the Action (M)odify or (D)ump field. The "0" (not a zero) in the (O)currs field means the edit line will be dumped into the source file a certain number of times. The (A)scending/ (D)escending field has no meaning here (see the next example), but the system requires something anyway, so an "A" is placed in this field. The next three fields determine how many times the line will be generated. The From field tells Expression where to start counting. If the user knows at this point how many times the line is to be generated, the user could enter this number in the To field. In this case it will be determined by the NUMBER OF FUNCTIONS line label, so that line label label is placed in the To Label Name field. The Class (0 or 1) field is rather like a usage class; class 0 means that the value of the To Label Name will be the upper limit of the occurs, and class 1 means that the number of occurrences will be the number of items within the screen or structure identified by the To Label Name : The control edit line goes onto the first of the three longest lines. The line label below acts only as a flag to determine whether the edit line will be dumped, so a usage class 0 may be used.

If NUMBER OF FUNCTION'S script question

(which will be something like "How many function keys do you want implemented?") us answered with "03", the line label will be activated, causing the line to be dumped into the source file, and its value (03) will determine the number of times it is dumped, producing:

SEND-TO-SERVER

Expression can also do the above while incrementing a counter within the line specifically, given:

NUMBER OF FUNCTIONS

it can produce:

F001

F002

F003

The control Definition Screen entry for this is much like the one discussed above and is shown in Table 24.

There are only three significant differences: the action is "M", since the control edit line is being modified; the line label NUMBER OF FUNCTIONS appear inside the control edit line; and the usage class is 9, which causes the incrementation to occur with each generation of the edit line.

The use of primary and subordinate line labels and script sub-sequences can help make large numbers of line labels easier to manage, since labels may be grouped together, and it can give a measure of control over them, since the subordinate line labels will never be activated, and their script questions will not be asked, unless there primary line label is activated. A subordinate line label may also be used as a primary for other line labels. The line labels related to the error-reply structure may be used as an example. There are four such error labels, i.e., ERROR REPLY itself, which is for the whole record, ERROR TEXT, FILE STATUS, and GUARDIAN ERROR, which are fields within the record.

The top three fields of the Model Configuration service, page 3 are used to make a sub-sequence out of a group of line labels. Assuming that these four line labels have already been defined, the sequence number of the ERROR REPLY is set as shown in Table 25.

ERROR REPLY here is subordinate to #START#, the root line label for every model. <F9> is pressed with the mode window on Assign Script Sequence.

ERROR TEXT'S sequence number is then set by putting ERROR REPLY where #START# was, and ERROR TEXT where ERROR REPLY was, and giving it the first sequence number for this sub-sequence, as shown in Table 26.

The sequence numbers for FILE STATUS and GUARDIAN ERROR are set the same way.

Each line label, its script sequence, its usage class, selection class, and other necessary information for entry in the model for the above requestor is listed in Table 27. The numbers are script sequence numbers; the indentations indicate which line labels are subordinate to which primaries. (2)(a) Creation of Data Base Structures

A data base is comprised of one or more files, each of which contains records that have a discrete structure. Records in one file are usually related to records in one or more other files. Related records must have at least one field in common. The common field is usually the key of one of the records in the relationship.

This type of relationship can be used to: - verify that a STATE CODE is valid before adding a new address record to the NAME AND AD¬

DRESS file, - find all the NAME AND ADDRESS records which have a particular state name, or

- find the full spelling of a STATE NAME when a NAME AND ADDRESS record has been read.

Whatever the intent of the program that accesses these two files, the problem will be easier to solve if the common field (STATE CODE) is identical in format.

In most data bases, similar fields may be found in many records across the files. A simple example is DATE. Again, programming is easier if every occurrence of a date has the same format.

The easiest way to build a set of files

(structures) is to identify each of the lowest level fields that will be used to describe the structures. These lowest level fields are known as base elements.

Base elements may be used to build more complex structures, which may be either complete structures or base groups. The base groups may then be used to build other base groups or complete structures.

Using DATE as an example, we immediately find that it is not a simple structure. It contains three elements: YEAR, MONTH, and DAY. These three elements are base elements. And DATE is a base group.

When a new structure is introduced to Expression, the system automatically generates a "DDL" scheme, and the actual data file, if applicable. Also, to make that structure and its data element definitions available for use by other application components, such as screens, functions, and programs, the system automatically makes the appropriate entries in an active data dictionary.

Two services in the Expression program are used for this, i.e., Structure Definition (AD.02) and Base Element/Structure Definition (SM.02). The only difference between the two services is that sharable structures (base elements and base groups) can only be created or accessed only from "Base Element/Structure Definition". Non-sharable structures (meaning they cannot be used as building blocks for other structures) can be created from either one. Access to (SM.02) may be controlled by system management for security.

To move around inside these services, <F4>,

<F5> and <F7> are normally used. <F4> (Read First) will display the name of the (alphabetically) first base element, base group, or structure for the currently selected application. <F5> (Read Next) will display the next, and so on. To see the first base element beginning with "C", a "C" is typed on the Structure Name line followed by (at least) one space, and <F5> is entered. An item's entire name may also be entered and <F7> (Read Exact) is used to locate a particular item.

When the desired structure is located, <F9> is entered to select this item. If the display says "Selected Item is in Use" at the bottom of the screen, that means another user is creating or updating this item on another terminal.

While working on a structure or base group, the Read function keys may be used to look at another structure or base element/group. The Read keys may be used to return to the item under construction.

To select a structure, when the mode window is not on Select Structure, <F9> is entered. The mode window will roll automatically to Select Structure, and <F9> may be entered again.

To use Expression most effectively, every base element should be created before any other work begins on an application. This can only be done in the Base Element/Structure Definition (SM.02) service for which the screen is shown in Table 28.

To introduce a base element to Expression:

1. The name is entered in the Structure Name field.

2. The word BASE is entered in the Class field. 3. With the mode window at Select Structure, <F9> is entered. "Cobol" will appear in the Language filed. A "D" for Design will appear in the Status field. The file Name field is ignored at this time.

4. The same base element name is entered on the first line under Element Name .

5. The base element's attributes are described on the corresponding lines under Type ("A" for alphabetic, "N" for numeric, "A N" for alphanumeric, "N C" for numeric computational), Length (if it's numeric, this must include the number of digits on both sides of. the decimal point), Sign , Dec (for number of decimal places), and Occurs (number of occurrences if you want it to be a table).

6. With the mode window on Create Structure <F9> is entered. When the terminal asks if a file is desired <F9> is entered.

This base element is now known to the system and is available for later use in building base groups and, eventually, complete structures.

To look at the COBOL source for this or any selected item the Read Text File mode window are used.

Essentially the same procedure is used to build a base group, except that existing base elements (and existing base groups) make the job easier and ensure consistency of definition. This can only be done in the Base Element/Structure Definition (SM.02) service as follows:

1. The base group name is entered in the Structure Name field.

2. The word BASE is entered in the Class field.

3. With the mode window at Select Structure, <F9> is entered. 4. On the lines under Element Name, the names of the base elements (or base groups) comprising the new base group are entered. Note that no two base elements inside any base groups or structure can have the same name, even if they are inside different (intermediate-level) base groups.

To see a list of all available active base elements, the List Base Elements mode window is used. The cursor is placed on one of them and <F9> is entered. This returns the user to Structure Definition, where the item may be deposited in the desired field.

The attributes need not be desired attributes. Instead, the mode window is rolled to Use Base Element/Group.

6. For each base element or base group name entered, the cursor is placed anywhere within that line and <F9> is entered.

If the selected item was a base element, the previously-defined attributes will be displayed in the right hand columns and a B (for Base) will be displayed in the Status column. To look at the components of a base group, the mode window to Designate/Read Group, the cursor is placed on the line containing the base group's name and press <F9>. To return to the highest level, the mode window is rolled to Exit Group Definition and <F9> is entered.

The name of the base element or base group may be changed after invoking Use Base Element/Group (but not the attributes). If the name of a base element or group is not appropriate for its immediate use, the original name is typed over after picking up its attributes.

7. When the attributes for all named base elements and groups have been filled in by the system, the mode window is rolled to Create Structure and <F9> is entered. <F9> is entered when the screen asks if a file is wanted.

This base group is now known to the system and is available for later use in building more complex groups and, eventually, complete structures.

After every base element and base group definition has been entered, structures can be created with either the Base Element/Structure Definition (SM.02) service or the Structure Definition (AD.02) Service. Such an entity is much like a base group, except that it is not sharable like a base group, and a file is also created, to hold its data.

Structures are created in essentially manner as just described for base groups:

1. The name of the structure is entered in the Structure Name field.

2. The word DATA is entered in the Class field.

3. With the mode window at Select Struc- ture, <F9> is entered.

4. On the lines under Element Name the names of the base elements and base groups are entered comprising the structure. Note that no two base elements inside any base group or structure can have the same name, even if they are inside different (intermediate-level) base groups.

To see a list of all available active base elements, the list Base Elements mode window is used. The cursor is placed on one of them and <F9> is entered. This will bring

Structure Definition, where the desired item in the field may be deposited.

5. Attributes are not entered. Instead, the mode window is rolled to Use Base Element/Group. 6. For each base element/group name entered, the cursor is placed anywhere within that line and <F9> is entered.

The previously-defined attributes will be displayed in the right hand columns and a B will be displayed under Status . If the selected item is a base group, a G will also be displayed under Status.

7. If alternate keys are required on any of the fields within the structure, that assignment must be made before the structure is created.

The mode window is now rolled to Set/Reset Alternate Key and <F9> is entered. An A will be displayed under Status . If an item is mistakenly assigned as an alternate key, pressing <F9> a second time will remove that assignment.

If the key is to be an elementary item and COBOL was specified in the Language field, the field must be non-numeric. If it is (and should be) numeric, a group name must be used to contain the item, since all groups are alphanumeric by definition. The user must re-select that base element and update it.

8. If the structure is to be a

key-sequenced file, the user will be asked to placed the cursor on the primary key field. In anticipation of this, the user should be sure the appropriate filed or group is displayed before pressing Designate/Read Group or Exit Group Definition modes are used until you are at the correct level within the structur As with alternate keys, the key field must be non-numeric for COBOL. Relative and

entry-sequenced files do not contain primary keys.

9. The mode window is rolled to Create

Structure and <F9> is entered. A "Y" is placed in the File(Y/N) field, the file-type (KEY, ENTRY, or RELATIVE) in the Type field, and the maximum number of records desired in the file is entered in the Number of Records field. The File Name field displays a Tandem file name. This will be the file that will contain the records being described. To enter a different name, the displayed file name is typed over.

10. <F9> is pressed to create the structure. When the structure is successfully created, it is ready for use elsewhere in the system. Its state (as indicated in the Status field at the top of the screen) will become A (for active) as soon as this service is exited or another structure or base element is selected.

To change the definition of a base element/group or structure after it has been created:

1. Select the item (with the Select Structure mode).

2. Roll the mode window to Prepare For Update and press <F9>.

3. Make the necessary changes.

(2)(b) Creating Screens

The screens required to access data in the fields created in the structure definition services are designed and created with the Screen Definition (AD.03) service. The copylibs containing the screen declarations can then be used in COBOL programs. This easy and convenient means of creating screens relieves the user of one of the most time-consuming tasks in writing requestors. To begin the process of creating a screen, go o page 1 of 3 of Screen Definition as shown in Table 8 and:

1. Enter the name of the new screen in the Screen Name field.

2. Since every I/O field in a screen must have an associated field in a previously-created structure, table to the Structure Name field and enter the name of the structure whose elements will be used by this screen.

3. With the mode window at Select Screen/Structure, press <F9>.

The definition of the named structure will appear for a few seconds and then page 2 of 3 of this service will be displayed automatically, as shown in Table 29.

Up to 20, 78-character screen definition lines can now be entered on this screen. I/O fields and filler (label) fields are depicted differently.

Each I/O field that will be displayed to the user at run time must be depicted here with a set of brackets, [ ]. There are three ways to control the size and format of this I/O field:

- Enter an asterisk between the brackets: [*].

The asterisk means the field on the screen will have exactly the same size and format as the element defined in the structure.

- Enter some number of spaces between the

brackets: [ ]. The element length from the structure will be expanded or truncated to fit between the brackets.

- Enter any legal SCOBOL screen picture between the brackets: [ZZ, ZZ9.99].

Most screen I/O fields will need some kind of identifying label, or prompt, so the end user will know what the I/O field is for. These filler fields are depicted, in Expression, with a set of parentheses. There are no rules about the characters between the parentheses.

Fillers not associated with any data field, such as headings and footings, must also be enclosed in parentheses. Fillers and data fields must end on the same line on which they begin.

The cursor-movement keys that work for most of the other Expression fields will work on this screen (the arrow keys, shifted RETURN to get to the beginning of a line, control-RETURN to get to the end of a line, etc.) The mode window can also be used to copy retrieve, delete, and insert lines.

Tandem's XVS may also be used to paint screens by involving the editor normally. Then, from page 2 and after selecting a screen, <F1> is used to go back to page 1, mode window is rolled to Load Edit File and the directions are followed.

A typical screen will appear as shown in Table 31 (in abbreviated form).

Display (or video) attributes are now assigned to every field on the screen. This allows the user to specify how the field will appear to the end-user: underlined, dim, blinking, etc. For each data (I/O) field, the data element with which it is associated is also selected with page 3, shown in Table 32.

The cursor is placed between any set of parentheses or brackets. With the mode window at Select Attributes, <F9> is entered.

- if the screen item is a filler, page three will be displayed. Any desired attributes are selected by placing an X in any attribute selection field. With the mode window in Assign Attributes <F9> is then entered. The cursor is then placed in the next field on the screen and <F9> is entered. - If the screen item is a data field, page 1 of 3 will be displayed. The cursor is placed on the element name to be associated with the screen field. If the desired element is within a group whose name is displayed, the user can get to it using the Read Group mode window. The user can get back out of it later using Exit Group. If the element desired is in a different structure, it can be accessed by using Select Another Structure.

With the mode window set to Select Data Element, <F9> is entered. Page three will then be displayed.

- The desired attributes are entered as above.

As each record is read, the field's assigned attributes and row and column number will be displayed. (The row and column numbers appear to the left of the Data Element Name header. Note that if there are two successive filler fields in this file, and the user does not assign any attributes to either one, and will see no change when going from one to the next except in the row and column fields.) Data element selections will also be displayed for I/O fields (in the lines titled From and To).

To assign the name of a filler as a synonym for its associated data field, the following steps are utilized:

1. Return to page two of the Screen Definition service and roll the mode window to Assign Synonym.

2. Place the cursor in either the filler field or the data field and press <F9>. The user will be asked to place the cursor in the associated field.

One synonym may be assigned to each data field on the screen. Any additional synonyms for the same data field are assigned in the Dictionary (AD.05) service.

After all attributes have been assigned (and synonyms, if applicable), the mode window is rolled on page 2 of 3 to Create Screen and <F9> is entered.

The screen is now ready for use elsewhere in the system. The screen's state will (as indicated in the topmost Status field on the screen) become A (for Active) as soon as the user exits this service or selects another screen.

(2)(c) Copylib Modules

Copylib modules bear the same relationship to copylibs that program models bear to programs. A copylib module, like a program model, consists of a copylib skeleton and its control instructions, script questions, etc. The skeleton is a copylib or (more often) a copylib section. Since copylib modules can be parameterized, they provide a way to tailor copylibs to the individual programs they are copied into.

The process of defining source line IDs, line labels, and scripts is basically the same for copylib modules as it is for program models.

A copylib module is usually a logic component (containing executable statements). There is generally no need to have a copylib module that contains a structure or screen declaration since these can be supplied other ways by Expression (usage 11, for example).

There are exceptions, however. For instance, if header or footer is used on all the screens in an application, it may be placed in a copylib module and sourced in wherever it is needed.

In general, a line label in a model whose replacement value is to be a copylib module must be given a usage class 20 or 21. A line label with usage class 20 will cause Expression to copy the module's copylib or copylib section into the generated source program line by line. This allows Expression to evaluate any source line ID's that are in the copied-in source. In addition, a commented-out copy statement is put into the source right after the source line ID. A copylib module can never (as a rule) have in its body a source line ID which has a line label declared with usage class 20. If it does, the generation process will cease.

A line label with usage class 21 will cause only the COPY statement for the module's copylib or copylib section to be put in the generated source program. This statement is built by Expression and deposited into the source right after the relevant source line ID. The source lines are therefore not brought in until compile time, so Expression will not have a chance to evaluate any source line ID's in the

copied-in unparameterized copylib modules. A module can have a usage class 21 in its source body.

An example of how to introduce a copylib module to Expression and use it with a program model to generate program is described below. The copylib module will be taken from the SPECIAL-NAMES part of the ENVIRONMENT DIVISION of the requestor in the earlier model described herein. It will be unparameterized, so it can take a usage 21. It is placed in a file called $STORAGE. SUBVOL.COPYLIB1. Assuming there are other things in COPYLIB1, a 7SECTION directive is placed at the top as shown in Table 33.

The user inters the Copylib Module Configuration service so the copylib module may be introduced to Expression. Since this copylib module is

unparameterized, only page 1 of the service is used. The desired logical name desired is entered in the COPYLIB Module Name field. The name of the source file is entered in the COPYLIB Source File field. Since this copylib is unparameterized an "N" is entered in the "Is COPYLIB a Usage Class 20?" field. Since there are other ?SECTIONs in the source file, "Y" is entered in the Multiple Section in copylib? field. The section name is entered in the Section Name field. The screen should appear as in Table 34.

To use this copylib module in the requestor model shown earlier it is necessary to replace the SPECIAL-NAMES part of the models skeleton with a source line ID. The user enters into the Model Configuration service, selects the requestor model, and goes to page 2, where the entries shown in Table 35 are made.

<F10> is now entered. Note that a line label with usage 20 or 21 must be the same as the logical name of an existing copylib module. This is a convenience feature which allows the user to have a script question for the line label - it will use the line label's name as the line label's value, and at program generation time it will bring in the source (or the COPY statement) for that copylib module. If, however, the user wants the option of choosing a different copylib module at program definition time, the line label can be given script question, and then if the question is answered, that answer will be used as the copylib module's name.

Assuming a script question is not desired for this line label, the line label is made automatic (selection class 0), so the line label will always be activated automatically and the copylib module will always be included in every generated program. (An automatic is a line label with selection class 0; it will always be activated automatically whenever its primary is activated, so it does not need a script question.) This information is entered on page 3 for this line label, <F10> is entered. For automatics, nothing is placed in the Required with Primary field, since there is not a script question. The Type field is left blank. If another, slightly different version of this copylib module was available, a selection class 2 could have been chosen, with a "U" in the Type field, and a script question could be entered. This would give the end user a choice of copylib.

A reasonable place in the script sequence is now chosen.

SDL##'s may also be placed in copylib modules just as in program models with usage class 20. The configuration service are the same as pages 2 through 5 of the Model Configuration service, and a coylib module's source line ID's and line labels are introduced in the same manner as for program models.

At program generation time, if Expression finds a usage 20, it copies the copylib module in line- by-line, and if, in doing so, it encounters an SDL- labelled line, it evaluates its source line ID right (making any required substitutions or additions) before copying in the next line.

There are times when it would be more convenient to do a second pass through a skeleton. Expression provides a way to accomplish this. SDL##'s are evaluated on the first pass, SDL@@'s on the second.

On the first pass through the skeleton, all the source line ID's in SDL## lines are evaluated. If any of the source line ID's were activated which have associated SDL@@ source line ID's, then the second-pass flag is set to ON. At the end of the first pass, if the second-pass flag is ON, then the user goes through the file again, and; if an SDL@@ is located, and its source line ID's parent source line ID was activated, any action implied by the current source line ID's line labels is also taken.

A copylib module can only have a usage 20 inside it if it is a second-pass usage 20. In other words, in a copylib skeleton, even though a first-pass source line ID can never have a line label declared with usage 20, a second-pass source line ID may. Usage 46 allows the user to copy a copylib module into a program a specified number of times, while incrementing a counter anywhere inside the

copylib module each time, analogous to control edit lines with usage 9. The user must fill in the Occurs fields on the Control Definition Screen, as for a usage 9. The line label which will act as the counter must be declared as a usage 46. It is declared inside the copylib module, while the usage 20 must be declared inside the model.

What follows is a pseudocode description of what happens:

On the first pass, if a line label with a usage 20 is found: For each Occurrence of the usage 20:

For each line in the copylib module:

Copy the line in the copylib module:

If it starts with SDL##

Then if the source line ID has a line label with

usage 46, replace that with the usage 20's current Occurs value

Else evaluate the source line ID normally.

As explained above, after the first pass is done, the second pass will evaluate any SDL@@'s. There is only one first pass and one second pass per program generation; there is no second pass for each individual copylib module. If put more than one usage 46 is placed inside a copylib module, then they will each produce the same values, for each generation of the copylib source. If a line label that holds a file name is NAME OF FILE 001, and the source line ID is DATA 001 INITIALIZATION, to produce move statements, it is given a control edit line:

MOVE SPACES TO NAME OF FILE 001. NAME OF FILE 001 is given a usage class 43. The control edit line will be generated once for each element in the structure, with NAME OF FILE 001 being replaced by the name of one of the elements in the file each time.

When doing this for more than one file, the problem is that if the DATA 001 INITIALIZATION source line ID is hand coded into the copylib skeleton, then it will always produce the initializations for the first date file, no matter which iteration of the copylib is being processed. The way around this is to make DATA 001 INITIALIZATION a second-pass source line ID, and on the line right before it put a first-pass source line ID which modifies it:

*SDL##STRUCTURE CONTROL VARIABLE

*SDL@@DATA NUMBER OF STRUCTURES INITIALIZATION

is changed to

*SDL@@DATA 001 INITIALIZATION

or

*SDL@@DATA 002 INITIALIZATION

On the second pass , the SDL@@ lines are evaluated normally. Note that this means that all the source line ID ' s which might be generated this way must be introduced to Expression previously, each in its own control record, as well as any line labels used in those control records . This is an inconvenience , but permits more flexibility in designing models .

To specify how many structures are desired, the Script Limiting Value field is used . It can be used in program models as well as copylib modules .

Suppose the user is to be limited to six structures . As described above , first source line ID DATA 001 INITIALIZATION is defined with line label NAME OF FILE 001 (usage 43 ) , source line ID DATA 002 INITIALIZATION is defined with line label NAME OF FILE 002, and so on all the way up to 6. The line labels NAME OF FILE 001 through NAME OF FILE 006 on the Line Label Definition Screen are defined, each with a reasonable script question. When defining the NUMBER OF STRUCTURES label, a "Y" is placed in the Script Limiting Value field and a "6" in the Limit field. The "Y" means that the user s answer to this question will limit presentation of questions in this line label 's script sub-sequence. The "6" is the value over which the user cannot go - if "07" is entered in answer to the question, the entry will not be accepted.

Since the "Y" affects the questions in this line label s sub-sequence, the user should put NAME OF FILE 001 here. If the question is answered with a 3, Expression sets up a counter to limit the number of questions in the sub-sequence which will be presented. Only line labels which are not automatic (selection class 0) and which are required (Required with Primary "Y") will increment the counter, so make sure to declare the NAME OF FILE line labels this way. When answering NAME OF FILE 001 s question, the counter is incremented by one; ditto NAME OF FILE 002 and NAME OF FILE 003. At this point the counter has reached its limit, so Expression climbs back out to NUMBER OF

STRUCTURE'S sequence and ignores any more line labels in this sub-sequence.

A fully commented version of a SCOB INIT DATA PROCS that initializes all the elements in all the user-specified structures to spaces as shown in Table 36.

There must be a source line ID (DATA INITIALIZATION PROCEDURES here) in the model's skeleton so Expression will know where to copy the new paragraphs into. It must be entered into the program models s

Control Definition Screen, but it may be placed in the copylib module too, for purposes of documentation if nothing else. The entry for it appears in Table 37.

Notice that the 2nd (P)ass field has a "P" in it; this means that this will be the parent source line ID to other, second-pass, source line ID s, namely DATA 001 INITIALIZATION, DATA 002 INITIALIZATION, etc. It is reasonable to hang these off of DATA INITIALIZATION PROCEDURES since they should not be activated unless the copylib is actually brought in, and DATA INITIALIZATION PROCEDURES determines whether the copylib is brought in. Notice also that though SCOB INIT DATA PROFS appears on the Control Screen here, conceptually the right place for its line label definition is in the model. Notice also that the occurs limit is NUMBER OF STRUCTURES. Though NUMBER OF STRUCTURES is used as the occurs limit here and in the control record for the PERFORM statement, its line label definition must be in the copylib module since it will have subordinate line labels there (NAME OF FILE 001, NAME OF FILE 002, etc.). The line label definition appears in Table 38.

Notice the script limiting value entries. Also in the copylib module are the definitions for the NAME OF FILE line, as shown in Table 39.

The control record definitions for DATA 001 INITIALIZATION, DATA 002 INITIALIZATION, etc., also go into the copylib module. First all the fields except the Primary Source Line ID field are filled in, and <F10> is entered as usual. The mode windows is rolled to Assign Second Pass, DATA INITIALIZATION PROCEDURES is put in the Primary Source Line ID field, and press <F9>. This tells Expression to look for DATA 001 INITIALIZATION in an SDL@@ LINE.

STRUCTURE CONTROL VARIABLE must also be entered into the copylib module s control file as shown in Table 40. The entry for the line label SCOB INIT DATA PROCS should go into the program model on page 3 of the model configuration service. After everything has been declared in both the model and the copylib module, the two are connected as follows: In the model, on DATA INITIALIZATION

PROCEDURE'S Control Definition Screen, the mode window is rolled to Catalog Copylib Module and <F9> is entered. Expression will go out and find all the source line ID and line label information for SCOB INIT DATA PROCS (at program definition time it will put all this from the model with those from the copylib module). A reasonable place in the model's script sequence is assigned and. SCOB INIT DATA PROCS is given a place in the script sequence.

The user can now generate programs. To generate a program that uses two structures, the chain of events is as follows:

Program definition time: When asked how many structures are desired, a "02" is entered. This will activate NUMBER OF STRUCTURES. Expression will set up an internal counter, with a limit of two. The line labels in NUMBER OF STRUCTURE'S sub-sequence will now be gone through. SCOB INIT DATA PROCS will become activated, since it s an automatic. Then NAME OF FILE 001 s question will be asked is entered, so the name of a structure is entered. This will activate NAME OF FILE 001 and increment the counter. A similar process occurs for NAME OF FILE 002. Now the counter s limit value has been reached, so NAME OF FILE 003 is ignored and the others and climb back out to the next highest sub-sequence.

At Program generation time, in the first first pass, reading through the skeleton Expression sees SDL##DATA INITIALIZATION PROCEDURES, which has been activated by its line label SCOB INIT DATA PROCS and whose control instructions tell it to use NUMBER OF STRUCTURES as a counter with an upper limit of two, and to bring in SCOB INIT DATA PROC's source that many times.

With NUMBER OF STRUCTURES set to 1, the source is copied in line by line. STRUCTURE CONTROL VARIABLE has been activated by its line label NUMBER OF STRUCTURES, so all of its source edit lines, including the SDL@@ lines, are modified such that NUMBER OF STRUCTURES is replaced with 001, as per the usage 46. The same process occurs with NUMBER OF STRUCTURES set to 2.

On the Second pass, looking through the source file, Expression sees SDL@@DATA 001 INITIALIZATION. Since its parent source line ID, DATA INITIALIZATION PROCEDURES, is active, and since its own line label, NAME OF FILE 001, is active, all the control edit lines containing the element names of NAME OF FILE 001 are generated as per usage 43. The same occurs for SDL@@DATA 002 INITIALIZATION.

Usage 43 produces all the fields in the structure, and spaces are moved into all of them. The only difference in this example is that the If Label # 1 is Type 18

Replace Label # ____

With NAME OF FILE 001 0 fields are filled in. The 1 after the If Label # refers to the first of the three line labels to the left (NAME OF FILE 001). Type 18 is one of the conditional types. It has the effect of not generating the control edit line for a given element unless the element is alphabetic or alphanumeric. The Replace Label # field is left blank since nothing is going to be replaced here; we only aim to suppress certain lines. The NAME OF FILE 001 in the With field will be dealt with later. Translated into English, these fields say: "For each field in NAME OF FILE 001, if the field is not alphabetic or alphanumeric, suppress generation of the control edit line."

To suppress the alphabetic/alphanumeric fields and generate only the numeric fields type 17 is used. Another source line ID (say DATA 001 INITIALIZATION NUMERIC) is needed but its control record definition will be exactly the same as the one above, except that there will be a 17 instead of an 18 in the Type field.

(3) Generating Programs

The only requirement for generating a new program in the Expression environment is that a program model has been previously configured and is active.

Generating programs does not require knowledge of a programming language.

The program model may require other components, such as one or more structures and one or more screens. This is entirely dependent on the design, intent, and options supported by the model.

The simplicity or complexity of the program generation process is dependent entirely on the model and its script. A simple model may ask for only a program ID and a structure name. A complex model may require dozens of responses to dozens of questions. An answer to any questions may cause other questions to be asked until sufficient information is obtained to en- sure correct generation of the final program.

The Program Definition/Integration (AD.04) service is used to define and generate programs from a model (see Table 41).

Before a program can be defined, it must be both registered and selected. Registering a program means making it known to Expression. This only has to be done once, before the first use of the program. The user must select the desired program upon coming, into this service.

To register a new program, the name is entered (this is its logical name so it may contain spaces) in the Program Name field. The name of the program is entered in the Model Name field. A list of all available models is displayed by invoking the Model List mode window which will also allow the user to select a model using <F9> and deposit it into this Model Name field. Finally the name of the object file is entered in the Object File field. For SCOBOL this field is left blank and it will automatically use the POBJ for the currently- selected application. If a different POBJ is chosen, it will use that until a final production object is created. For other languages the user must put a filename in the Object File field. Source File can be left blank; the system will generate the name of the program's source file here. Any pertinent comments are placed in the Comments field. The mode window is rolled to Register Program and <F9> is pressed. The program will be registered and selected automatically and page 2 will be displayed.

If the user comes into Program Definition/Integration and wants to use a previously- registered program, the Read keys are used to find it. <F9> is pressed with the mode window on Select Program.

There will be a short delay while the system builds the files required to support the program generation.

<F9> is pressed to get to page 2 of the service. This is where the user answers the mode's script questions.

The typical first question will appear as in Table 42. Either one or two data entry fields will be available beneath the question. The REQUIRED to the right of the questions means that Expression requires an answer to this question (since its Required with

Primary field on page 3 of the Model Configuration service was given a "Y"); so the user must answer the question and press <F9> (with the mode window at Accept Entry). If OPTIONAL is displayed instead of REQUIRED then the user can legitimately skip over the question with the <F5> (Read Next).

Below the REQUIRED/OPTIONAL field is a field that tells the status of the ON/OFF flag for this line label (which governs whether the line label is activated). If it is off, the field will be blank; if it is on, it will say ON. It is turned on when the question's answer is accepted. If, for some reason, the user wants to turn the flag off, the user can use the Revoke Entry mode window.

If the user is going through a script for which the questions were previously answered, the previous answers will be displayed. <F9> (with the mode window at Accept Entry) will make it accept the same answer; <F5> will allow the user to skip over the questions, leaving the answer unchanged. The effect is the same, except that <F9> will also cause the questions of any subordinate line labels to be presented, and <F5> will not.

Table 43 illustrates some of the features of script definition. First, when a response to a primary line label's script question causes the subordinate line labels' questions to be asked, the initial script question and the user's answer are displayed in the middle third of the screen. The current question is displayed in the bottom third.

Second, if the line label has selection class 3, it prompts the user for the structure or screen name:

Enter Structure Name ERROR DATA Third, if the line label has selection class

4, as in the bottom question, it prompts the user for both the element name and the structure/screen name. Note that the element name field is case sensitive;

this can cause problems if the user types in lower case, and it was defined as upper-case elsewhere. (In general, the user can tell whether a field in Expression is case- sensitive by typing it in lower-case, and entering it into the file. If it is re-displayed in upper-case, the field is not case-sensitive; if it stays in lower-case, it is.)

The user may move around inside this service as follows:

- <F4>will take the user to the first

question of whatever branch of the tree the user is presently on.

- <F9> always takes the user to the next question, no matter what branch it is in; and it always makes the current question s answer be accepted.

- <F5> takes the user to the next question of the branch he/she is on, or (if at the end of the branch) to the next question in the next highest branch; <F5> never causes a question s answer to be accepted.

- If the user is down inside the tree and wants to get back to the very first question, the Read Start Of Script mode window is utilized.

- If the user wants to get to the next

lowest branch without having to worry about the answer of the current question, the user uses Read Related Questions.

- If the user is down inside the tree, Exit Related Questions will get the user to the question of that branch's primary line label. - There is no quick way to get back to the immediately previous questions; <F4> followed by <F5>'s is the best way. The user must Update Script before answering the script questions if the user has changed anything on page 3 of Model Configuration (which deals with most of the line label related information). If the user has changed the script sequence the user must Clear Program Script and re-answer all the questions.

When all the questions have been answered, the user may use combination of <F4> and <F5>, as well as the mode window options, to review answers and change them, if necessary. When satisfied with the answers, the user returns to page one.

If the user wants to wait some period of time before generating and compiling the program, the user simply exits from this service. The responses will be saved until the user returns and selects the same logical program name.

Three things must be done before the user is ready to use the final program. The user must:

1) Generate the source program;

2) Compile the source program;

3) Catalog and store the compiled program.

This means letting Expression know what screens, structures and copylib modules it references.

(Also, if the program is in SCOBOL and the user compiled it to a POBJ different from the application's default POBJ, it will use the default anyway. This is not really a part of cataloging, but for purposes herein can be thought of as such). This is also called activating the program.

Various mode windows accomplish these things in various ways:

Generate Program Source accomplishes step 1 above. If this is the first time a program model has been tested after configuration, the Generate Program Source mode can be useful. A model with many optional script questions, many branches in its script, and extensive use of the automatic selection class may require considerable "script testing" to be sure the configuration is right.

Compile Program Source accomplishes step 2 above;

Catalog Compiled Program accomplishes step 3 above;

Create Test Program accomplishes steps 1 and 2 above, and causes the compile to be done with symbols so the user can use Inspect; and

Create Final Program accomplishes steps 1, 2, and 3 above; it should be used when the user is fairly confident of the model responses. The program created can then be run or otherwise utilized by executing the program.

These functions can be invoked with shifted <F9> as well as <F9>, so that they will run NO WAIT and not lock up the keyboard. As a rule, any mode window function that takes a long time can be invoked with shifted <F9>. Then the user can display the status of the background job with <F13>.

To other mode windows are also useful here:

Read Text File lets the user look at the generated source program. Sometimes error messages show up here.

Look at Compile results displays the compiler listing. This is sent to Peruse. The compiler listing is usually a recent job that has a lot of pages. It is sent to the spooler location specified as the Out File under the OUT DEVICES heading in the SDL Configuration service. Error messages may also be sent to Peruse, to a different location. Catalog List displays a list of all the copy lib modules, screens, etc. which are used in the selected program.

If the user wants to generate the program again later using different script responses, the user first uses Select Program, then changes answers. If any of the structures, screens, or copylib modules that the program uses have been changed, the user must catalog it again.

When the program has been integrated, if it is a SCOBOL requestor and the user wishes to run it from Expressway, the user must invoke the END USER ENVIRONMENT (on the WELCOME TO EXPRESSWAY menu). The compiled pseudocode resides in the POBJ named in the Application Directory record built when the application was first registered. The TCP in the application development facility does not know about this POBJ file. Invoking END USER ENVIRONMENT causes the TCP terminal thread in the application development facility to be suspended. A temporary program definition is added to the PATHWAY configuration provided for testing and that program is run. A logon screen will be presented.

Logon is then carried out as usual. From any of its menus, the user can type in the logical name of a requestor and press <F9>. When finished with this environment, the user may exit all the way back to the previous one using shifted <F16>. The temporary program definition will be deleted and the user's previously- suspended terminal thread will be resumed.

(4). Glossary

The following terms are used herein and in the attached source code and are described, defined, and illustrated with examples as follows: 1. Application Made up of entities: elements,

groups, structures, screens,

models, COPYLIB modules, and

programs. There can be any

number and combination of these in an application, depending on its individual requirements. 2. Attribute A characteristic that can be assigned to a field on a screen. For example, if the dim attribute is assigned to a field, the field will appear fainter than normal mode. 3. Base Elements, groups, and structures that can be used as building blocks for structures. They are created in the Base Element/Structure Definition (SM.02) service with BASE in the Class field.

4. Base element See Element. 5. Base group See Group.

6. Base structure See Structure.

7. Catalog A cross-reference of relationships among Expression entities. Expression maintains two catalogs: the Where Used Catalog (SM.15) displays, for a given entity, all other entities that reference it; the Using Catalog (SM.16) displays, for a given entity, all entities that are referenced in it. Any changes to entities are automatically recorded in these catalogs. The information provided by catalogs can HP uspd to project the impact of any proposed change in an application to other parts of the application.

8. Configuration file A file in Expression. There is only one configuration file per Expression system. Its primary key is an Expression name. Each record in the file has pointers to the directories, the catalogs, a list of users, and so on, that apply to that system. For most groups of users there will be only one record in the

configuration file, and its primary key filed will have the value DEMO. 9. Control edit line See "edit lines"

10. Control file An internal Expression file that

keeps all the control instructions for a model. There is a one-to-one correspondence between models and control files.

11. Control Instructions The invention's internal representation of what will happen to the source associated with a particular source line ID, such as what things in the source should be modified; how those things should be modified; whether the source is located inside the model's skeleton or right there in the control instructions, or in a copylib; etc. The user types the control information at the Model Configuration

Control Definition screen.

12. Control record The record that includes all the information entered on the control definition screen for a particular source line ID. This record is entered into Expression's internal control file. Along with the script responses for the relevant line labels, a control record has all the information needed for Expression to do, at program generation time, the source modification and/or source generation for a particular place in the skeleton. There is always a one-to-one

correspondence between a control record and its source line ID

(although a source line ID can be put into more than one SDL-labeled line in a skeleton). A control record can have other control records subordinate to it; these records have SDL@@ labels and are evaluated on the second pass through the skeleton.

13. Control record A control record becomes

activation activated if any of its line

labels arp activated. Much the same as source line ID activation.

14. COPYLIB module An enhanced COPYLIB section that may be parameterized in Expression to contain the code for a procedure, a function, a set of base screens with standard formats, working storage variables, or any other piece of code that is a candidate for repetitive use or that can be managed more efficiently under system control. COPYLIB modules are used within models to generate programs. They are created in the COPYLIB Module Configuration

(AD.06) or Base Element/Structure Definition (SM.02) service. 15. Data Refers to elements, groups, or structures that cannot be used in other groups or structures (as opposed to a base elements, base groups, or base structures, which can be used in other groups or structures). Created in the Structure Definition (AD.02) or Base Element/Structure Definition (SM.02) service.

16. Data dictionary Expression's active data

(active) dictionary holds an entry for

every base element, group element, structure, screen, and screen element for a particular application. It is called active becouse the relevant entry is automatically updated each time an entity is changed (for instance, when a structure is updated).

17. Data elements Fields on screens that contain input or output information.

18. Dictionary slice File that contains all references to the particular data elements of a structure and screen, with one entry for each different name assigned to a data element. 19. Directory A table of a type of Expression

entities or objects, along with the information that Expression maintains

about that entity. Expression

has six directories: Application

Directory (CD.01), Structure

Directory (CD.02), Screen Directory (CD.03), Program Directory (CD . 04) , COPYLIB Modu l e Directory (CD.06), and Model Directory (CD.07). Any changes to entities are automatically recorded in these

directories.

20. Edit Lines Source statements whose classification determines how they can be manipulated when, and if, they are included in a generated source program: a. Source edit lines are modifiable lines, which the user

leaves in the model's skeleton file, which will be included in every program generated from the model. They are always immediately preceded by SDL-labelled lines.

Each source edit line must

have at least one modificable parameter (line label), and can have as many as nine. The PROGRAM-ID PROGRAM NAME. statement used earlier in the example is a source edit line that will always he included in every generated program. Each time a new program is being defined from the model's script, a different value can be given for the PROGRAM NAME line label. Control edit lines are source statements that reference elective, modifiable data components. They are the statements removed from the source file and written on the Model Configuration Control Definition screen;

whether they will be included in a particular source program can be determined at program definition time.

A control edit line can be copied as is into the program source, or it can contain up to three line labels that can be modified before the line is copied. 21. Elective, modifiable Parts of a source program written program components in a particular language that need not always be present for the program to be compilable. If present, they may take different forms. An example is a SCOBOL line such as:

02 SCREEN-STATUS OCCURS 2 TIMES.

Other examples are recorded definitions, I/O operations, and functions.

22. Element The lowest-level component of a structure nr group. An element may be base or data. A base element may be used as part of other groups or structures; a data element may not be so used. Elements are created in the Structure Definition (AD.02) or Base Element/Structure Definition (SM.03) service. A base element is Expression's equivalent of a variable declaration, and is much like an elementary data item in COBOL.

23. Entity Refers to any of the components that make up an Expression application: an element, group, structure, screen, program, COPYLIB module, or model. 24. Environment Expression term used to refer to a collective set of users,

catalogs, directories, and

applications. 25. EXPLOG The log file Expression creates

for the export procedure in which it collects all warning and error messages.

26. Export procedure A procedure, in Expression used to collect all Expression files that are associated with an application, and to copy them to one or more Tandem suhvolnmes. The Tandem backup utility can then be used to make a copy of the entity for transfer to another system. The export procedure is also used when an Expression application must be moved or copied from one

Expression environment to

another.

27. "Expression" An environment which is a

collective set of installation parameters, users, applications, and all the components that support the makeup of those applications. More that one Expression environment may exist on the same Tandem system, but each one is totally independent of the others. They do not generally share anything. 28. Expression name Also called the configuration name.

The name of a particular Expression environment. Each Expression environment has its own set of users, catalogs, directories, and applications. Logging on is the act of invoking a particular Expression environment. The Expression name is the key to one of the records in the configuration file.

29. First pass At program generation time,

Expression reads through the parameteri zed source file and evaluates all the liens beginning with SDL##.

30. Fixed, modifiable Parts of a source program written program components in a particular language that must always be present, but need not always have the same form, for the program to be compilable. An example is the WILLIAM SHAKESPEARE in the following line from a COBOL program:

AUTHOR. WILLIAM SHAKESPEARE.

From the point of view of a particular model, a source edit line with a line label can also be regarded as fixed, modifiable, since it will always be included in any generated source program but can be modified. 31. Fixed, non-modifiable Parts of a source program written program components in a particular language that must always be present and must always have the same form for the program to be compilable. An example is the following line from a COBOL program:

DATA DIVTSTON.

From the point of view of a particular model, things hard-coded into the skeleton can also be regarded as fixed, non-modifiable, since they will always be included in any generated source program.

32. Group A structure made up of more than one element; or a structure made up of other elements and base groups. Used as building blocks for other, more complex base groups and structures. Groups are created in the Structure Definition (AD.02) or Base Element/Structure Definition (SM.02) service. A base group is much like a group data item in COBOL.

33. IMPLOG The log file Expression creates in which it collects all warning and error massages for the import procedure. 34. Import procedure A procedure in Expression used to integrate all the files associated with an application into the

Expression environment.

35. Installation Consist of such things as the

Parameters unique name by which the environment will be known and the names of the basic files Expression needs in order to operate. A system manager can change most parameters as need dictates.

36. Invoke Activating selecting a mode window function or selecting an item from a menu. This is done by pressing <F9> (Invoke).

37. Level part of the security identification for a user that is set up by the system manager.

38. Line control type One of the fields on the control definition screen. Type 2 means that the source line ID deals with a source edit line. Type 1 means it deals with a control edit line, a COPYLIB module, or other entity which involves no source edit line, such as a COPYLIB which contains a structure/screen declaration and which was created in the Structure Definition (AD.02) or Screen Definition (AD.03) service. 39. Line Labels Variable portions of source code.

The user puts them inside control or source edit lines. They take on their value at program definition times (usually the value depends on the response to a script question). The value of the line label is substituted for the line label in the source line at program generation time.

Line labels act as flags. If a line label does not appear in its associated control pdit line, it serves only to decide whether the line is dumped into the generated source program, and this only happens if the line label is activated.

The two major attributes, or characteristics, control the manner in which input from the user is treated. The two input attributes are, for example, the selection class and the

usage class. The selection class determines how the line label will be activated. The usage class determines what will be done to the line label if the source it is a part of is included in the generated program. Line labels do not do anything unless they are activated. Based on its selection class a line label will be activated automatically when its primary line label is activated (selection class 0), or when the user simply hits <F9> in response to its script question (selection class 1), or when the user types in a response to its script question. In the last case, the selection class allows the user to specify the type of information required in that response: - any value at all (selection class 2); - the name of the screen or

structure (selection class 3); - the names of a screen and an element within the screen, or a structure and an element within the structure (selection class 4); or - the names of a FROM structure and a TO structure or the names of a FROM screen and a TO screen (selection class 5. This is for MOVE

CORRESPONDING' s). Once a line label is activated, then wherever it appears in its source it will be replaced by its value (which is determined by its usage class); if it is associated with a control edit line, that line will be dumped into the generated source program, whether the line label is a part of the source line or not.

The usage class determines what will happen to a line, label once it has been activated. Most usage classes tell Expression to get a certain value from a certain place and replace the line label with that value. Usually that value comes from an active data

dictionary.

The attached appendix version of the software includes about 50 usage classes.

39. Line label activation A line label is activated if its

ON/OFF flag is on. If activated, at program generation time: (1) the line label embedded in any (control or edit) source line it is associated with will be

replaced with the line label's value (as determined by its usage class); (2) any associated control edit line, COPYLIB module, or internal COPYLIB will be dumped into the source file; (3) if the line label is a primary line label, then its subordinate line labels may become activated.

40. Line label Page 3 of the Model Configuration definition screen (AD.07) service or COPYLIB Module

Configuration (AD.06) service.

41. Literals See Scrpen literals.

42. Logon ID The user ID/password combination that allows the user to logon to Expression.

43. Model activation Releasing a model for use in

generating new compilable source programs. This happens after the control and script information has been defined in the Model Configuration (AD.07) service. 44. Model configuration Providing a model control and

script information (minus the script responses) so that programs can be defined from it. This is done in the Model Configuration (AD.07) service.

45. Mode window Boxes at the bottom of the screen in a service that contain the names for functions that can be performed within that service. A mode window is invoked by moving it into the center position and pressing the <F9> (invoke) function key. Mode windows are shifted from the left or right into the center position by means of the <F3> (Roll Left) and

<S/F3> (Roll Right) function keys.

46. MSTR Default user ID for the system

manager.

47. On/OFF flag An internal Expression flag (one per line label) that governs whether a line label is activated. If the label has selection class 0, it will automatically be set to On (if its primary line label is activated); for any other selection class, it will be set to ON if its script question is answered. It is used at program generation time.

48. Parameterization The process of identifying the

optional and/or modifiable parts of a source program. Also, the process of writing the control instructions and script

directions that make program definition and generation

possible.

49. Parameterized source A source file written in a language edit file such as SCOBOL, COBOL, or TAL, which includes SDL components (SDL labels, source line ID's, line labels, etc.). These components are used at program generation time by Expression to produce a compilable SCOBOL, COBOL, or TAL program. Any number of compilable source programs can be produced from one parameterized source file. Also called a skeleton. 50. PATHWAY See Configuration file.

configuration file

51. Primary line label The first line label for every

script is #START#. Similar to the nodes of a tree, with #START# at the root of the tree, a line label's primary line label is a label that must be activated before it can be activated.. A line label's parent label is called its primary line label.

52. Primary source A source line ID whose SDL label line ID is SDL## and which has associated second-pass source line IDs.

53. Program Model A program skeleton that contains the architectural logic required by a particular programming language, some lines of code that will be included in every generated program, and SDL-labels, source line ID's, and line labels that identify what parts of the skeleton are subject to change.

Also part of a program model are the control instructions, the script, and optional second pass associations. Control instructions and second pass associations serve as SDL's internal representation of what can be done to the skeleton; the script is the

sequence of questions presented to the user in order to get the additional information needed by the control instructions to turn a skeleton into a particular program.

54. Pseudocode File that holds the PATHWAY

object file requestor object file into which all screen programs associated with an Expression application will be compiled.

55. Registration Making a new entity (such as an application, program, or program model) known to Expression. This only needs to be done once.

56. Screen attribute See Attribute.

57. Screen image file File that contains Expression's image of screens.

58. Screen literals Fields on screens (such as

titles, prompts, and fillers) that do not change.

59. Script The programmer-defined set of questions presented to text user at program definition time as a step-to-step guide in activating line labels and setting their values, so as to produce a compilable program at program generation time. 60. Script definition Information about a script that can be typed in at model configuration time (sequencing, selection class, the actual question, etc.).

61. Script directions Answers to the script questions.

More precisely, the information needed (along with the control instructions) to change a parameterized source file into a particular compilable source program at program generation time. This includes such things as the setting of the ON/OFF flag and the actual answer to the question.

62. Script question A question associated with a line label that is presented to the user at program definition time. It is entered on page 3 of the Model Configuration (AD.07) service.

63. Script sequence The order in which the script

number questions are presented to the user at program definition time is determined by the question's script sequence numbers. These numbers are established on page 3 of the Model Configuration (AD.07) service. There is a one-to-one correspondence between script sequence numbers and line labels; and there is a one-to-one correspondence between script sequence numbers and questions presented to the user at program

definition time. (An exception is that no script question is needed if the line label has a selection class of 0.)

64. SDL (Source The part of the invention that

Definition makes it possible to separately

Language) define program components

(structures, screens, etc.) that, if identified in a program model, can be integrated into any number .of application programs. The intent of SDL is to allow the user to conveniently generate, control, and manage much of the source associated with application programs which are being generated and maintained.

65. SDL@@ Default source line ID for the

system's second pass through the code in a program.

66. SDL## Default source line ID for the

system's first pass through the code in a program.

67. Control The invention's internal repre¬

Instructions sentation of what will happen to the source associated with a particular source line ID, such as what things in the source should be modified; how those things should be modified; whether the source is located inside the model's skeleton or right there in the control instructions, or in a

copylib; etc. The user types in the control information at the Model Configuration Control

Definition screen.

68. SDL-labeled line A comment line inside a skeleton file that has an SDL label after the comment indicator.

69. Second pass An optional process in which

Expression can be made to go through the source file a second time, if everything could not be accomplished the first time through the file or if it is more convenient to perform something the second time around. If

Expression encounters any SDL@@ lines with associated activated SDL## lines during the first pass, it will read through the source file again and evaluate those SDL@@ lines during the second pass.

70. Second-pass The link between a control record association with an SDL## SDL label and a

subordinate control record with an SDL@@ SDL label. 71. Second-pass source A source I ine ID whose SDL label line ID is SDL@@. Its line is ignored during Expression's first pass through the source file. It must have an associated primary source line ID, and it is only evaluated during the second pass if its primary source line ID was activated during the first pass.

72. Selection The act of notifying Expression which entity will be used for the function about to be. performed. This initializes the appropriate dictionary, catalogs, and directories for the application. Applications, programs, and models must be registered before they can be selected.

73. Selection class The selection class of a line label determines two things: (1) how the line label will be activated, and (2) how (and whether) the user will be prompted at program definition time. For instance, if a line label has a selection class of 0, the line label will always be activated automatically whenever its primary line label is activated, and the user will not get prompted for it at program definition time. See also Usage class. Each Selection class is described in Table 24. 74. Service Services are the major divisions of functions within Expression. For example, Application

Development and Model Configuration are services. In Tandem terminology, a service represents a requestor-server relationship. Each service is identified by a unique service ID.

75. Service ID Unique ID for each Expression

service. For example, the service ID for the Application Selection service is AD.02. The service ID appears at the top left of the screens used in services.

76. Sharable Entities are either sharable or non-sharable. If sharable, they can be used by any application in the Expression environment. If non-sharable, they can only be used by the entity in which they were created. Entities are non- sharable unless explicitly made sharable by a mode window made available for this purpose.

77. Skeleton Same as parameterized source edit file. See Parameterized source edit file.

78. Source edit line See "Edit Lines' 79. Source Line ID The link between an SDL-labelled line and its associated control instructions (see below). In order for the system to make this association, the source line ID, which the programmer types in at the Model Configuration Control Definition screen, must also be put in the program skeleton following an SDL## or SDL@@m e.g.:

SDL-labelled line: *SDL##PROGRAM

IDENTIFICATION

Source Line ID: PROGRAM

IDENTIFICATION

80. Source line ID A source line ID becomes

activation activated if any of its line

label is activated. If

activated, any modification or source dumping implied by the usage classes of the line labels will take place at program generation time. Much the same as control record activation.

81. Structure The basic building block of

applications. Structures are storage areas that hold the data used everywhere in Expression. A structure may be made up of elements, groups, or other structures. It (and its

components) may be base or data. A base structure is one which may be used as part of another structure; a data structure may not be so used. Structures are created in the Structure

Definition (AD.02) or Base

Element/Structure Definition (SM.02) service.

82. Structure image File that contains the Expression file image of user definitions of

elements.

83. Synonym If an element in the data

dictionary is to be called something different, the second name can be entered in the dictionary as a synonym for the original name. The element can then be referenced and manipulated by either name. Synonyms are assigned in the Screen Definition (AD.03) service with a special mode window.

84. System manager The individual in an installation who has administrative responsibility for the Expression system. The default user ID for the system manager is MSTR.

85. Type Part of the security identification for a user that is set up by the system manager. Used to group together users who have similar security privileges. 86. Usage Class The usage class of a line label determines what will be done to the line label if it becomes activated. For example, if a line label has usage class 8, then the label will be replaced with the internal name of a record. Although a line label can have only one selection class, it can have different usage classes, one for each time it appears in the control instructions. Each usage class is described in Table 25, and includes a list of selection classes which is valid for each usage class.

identification division.

program-id. simple-prog.

author. Sam Clemens.

environment division.

configuration section.

source-computer. T-16.

object-computer. T-16.

^/ data division.

^/procedure division.

only-paragraph.

display "This is a sample program.", stop run.

TABLE 1

SELECTION

CLASS DESCRIPTION 0 AUTOMATIC SELECTION - users don't see a question for this line label; it will be automatically activated, along with any other related line labels, when its primary line label is activated.

Valid Usage Classes: 0, 20, 21, 33 1 SELECT ONLY - the line label will be activated if the user hits <F9> with the mode window on Accept Entry; no value need be typed in.

Valid Usage Classes: 0, 20, 21, 33

2 ENTER VALUE - user must provide a specific value.

Valid Usage Classes: 0, 9, 20, 21, 46 3 ENTER SCREEN/STRUCTURE NAME - user must provide the name of a screen or a structure.

Valid Usage Classes: 8, 10, 11, 12, 13, 14,

18, 24, 25, 28, 29, 30, 32, 42, 43, 45, 47, 48, 50

SELECTION

CLASS DESCRIPTION

4 ENTER SCREEN/STRUCTURE AND ELEMENT NAMES - user must specify a screen or a structure, AND an element within the screen/structure.

Valid Usage Classes: 1, 2, 3, 4, 5, 6, 7, 15,

16, 17, 19, 22, 23, 26, 27, 32, 44, 49 5 ENTER FROM/TO SCREEN/STRUCTURE NAMES - user must specify a FROM screen and a TO screen or a FROM structure and a TO structure.

Valid Usage Classes: 34, 35, 36, 37, 38, 39,

40, 41 ===============================================================

TA B LE 12

VALID

SELECTION

USAGE DESCRIPTION CLASS

0 VALUE/COPYLIB NAME - Replace label with 1 or 2 or user's script response. Used with control or

blank source edit lines. ("Action" = Modify)

Dump control edit line. ("Action" = Dump) 1 (STRUCTURE) UNQUALIFIED INTERNAL DATA ELEMENT 0, 1, 2 NAME - Replace label with unqualified

internal name of a data element in a

structure. (The label must be for a

structure, not for a screen.) 2 (STRUCTURE) FULLY-QUALIFIED INTERNAL DATA 4 ELEMENT NAME - Replace label with internal

names of a data element and its associated

structure, fully-qualified in appropriate

language syntax. (The label must he for a

structure, not for a screen.) 3 (STRUCTURE) DATA ELEMENT LENGTH - Replace 4 label with length of data element. 4 chars.

4 (STRUCTURE) DATA ELEMENT INDEX - Replace 4 label with data element's position in the

structure (counting group elements as well as data elements). 3 chars. 5 (STRUCTURE) DATA ELEMENT OFFSET - Replace 4 label with data elements' byte offset in the structure record. 5 chars.

TABLE 13 VALID

SELECTION

USAGE DESCRIPTION CLASS

6 (STRUCTURE) LOGICAL DATA ELEMENT NAME - 4 Replace label with logical name assigned to

the data element during screen or structure

definition.

7 (STRUCTURE) FULLY-QUALIFIED LOGTCAL DATA 4 ELEMENT NAME - Replace label with logical

names assigned (in a definition service) to

the data element and i ts associ ated screen or structure.

8 (STRUCTURE) INTERNAL STRUCTURE NAME - Replace 3 label with structure record's internal name.

9 CONTROL EDIT LINE INDEX - Treat the line 2 label in the edit line as a counter.

Increment/decrement the value of the counter for the number of times determined by the

FROM/TO fields; for each value, generate the line once, replacing the line label with the value of the counter each time. Used with

control edit lines only. The counter will be 3 chars wide. ("Edit Control Occurs" must be "0").

10 (SCREEN) SCREEN COPY STATEMENT - Replace 3 3 label with COPY statement for COPYLIB section containing the screen's SCOBOL declaration.

Any associated control/source edit line is

ignored.

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

11 (STRUCTURE) STRUCTURE COPY STATEMENT - 3

Replace label with COPY statement for COPYLIB section containing specific language

declaration of the structure record.

Ctrl/source edit line ignored.

12 (STRUCTURE) UNQUALIFIED FILE NAME - Replace 3 label with (Tandem) file name of the

structure/record (no vol/subvol).

13 (STRUCTURE/SCREENO LOGICAL STRUCTURE/SCREEN 3

NAME - Replace label with logical name

assigned (in a definition service) to the

structure or screen, with appropriate

language separators.

14 (STRUCTURE) FULLY-QUALIFIED INTERNAL PRIMARY 3

KEY ELEMENT - Replace label with internal

name of data element designated as the

structure's primary key, fully-qualified in

language syntax. If it is a relative file, the replacement value is the structure name

with appropriate language separators, with

"RELKEY" appended to the end; this can be

used in conjunction with Usage 30.

15 (SCREEN) INTERNAL SCREEN I/O ELEMENT NAME - 4

Replace label with screen I/O field's

internal name.

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

16 (SCREEN) SCREEN ELEMENT'S ROW POSITION - 4

Replace label with row position of screen

field.

17 (SCREEN) SCREEN ELEMENT'S COLUMN POSITION - 4

Replace label with column position of screen

field. 2 chars.

18 (STRUCTURE) STRUCTURE/RECORD LENGTH - Replace 3 label with length ( in bytes ) of

structure/record. 5 chars.

19 (STRUCTURE) DATA ELEMENT OCCURS COUNT - 4

Replace label with "occurs" value assigned to data element during element or structure

definition. 3 chars.

20 COPYLIB MODULE DUMP - Dump entire COPYLIB 0, 1, 2 module, line-by-line. The line label name

must be the same as a COPYLIB module name, so no script question is necessary, but the

COPYLIB module can be changed anyway by means of a script question. No COPYLIB module can

have a usage 20 inside of it. (Any

associated control/source edit line is

ignored.)

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

21 COPYLIB MODULE COPY STATEMENT - Dump only the 0, 1, 2

COPY statement for COPYLIB module. The line

label name must be the same as a COPYLIB

module name, so no script question is

necessary, but the COPYLIB module can be

changed anyway by means of a script question. (Any associated control or source edit line

is ignored.)

22 (STRUCTURE) DATA ELEMENT HELP FTLE - Replace 4 label with (Tandem) file name of the data

element's Help file.

23 (STRUCTURE) DATA ELEMENT VAL.DATTON FILE - 4

Replace label with (Tandem) file name of the data element's Validation file.

24 (STRUCTURE) FULLY-QUALIFIED FTLE NAME - 3

Replace label with fully-qualified (Tandem)

file name of the structure/record.

25 DICTIONARY SLICE FILE - Replace lahel with 3

(Tandem) file name of the dictionary slice

associated with the structure. The

dictionary slice may contain screen entries

if a screen has been painted against it.

26 (SCREEN) SCOBOL SHADOW BYTE PIC CLAUSE - 4

Replace label (in working storage) with a PIC 9 clause corresponding to a screen field that has been assigned the SHADOWED attribute.

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

27 (SCREEN) SCOBOL SHADOW BYTE NAME - Replace 4 label (in Procedure Division) with internal

name of the data element that corresponds to

the shadow byte definition.

28 (STRUCTURE) STRUCTURE DECLARATION - Replace 3 label with specific language declaration of

the structure record, starting at a

user-determined lexical level number. (Any

associated control or source edit line is

ignored).

29 (STRUCTURE) STRUCTURE DECLARATION - Same as 3

Usage Class 28 - without VALUE clauses. For use in SCOBOL linkages and COBOL FDs .

30 (STRUCTURE) RELKEY DECLARATION - Replace 3 label with the WORKING-STORAGE declaration of the relative key referred to in the

description for Usage 14.

31 (STRUCTURE) RELKEY NAME - Replace line label3 3

(in Procedure Division) with internal name of the relative key referenced in the Usage

Class 14 description.

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

32 (STRUCTURE) ALTERNATE KEY ID - Replace label 4

with the keytag (Enscribe alternate key ID)

of a data element designated as an alternate

key to the structure. If the keytag is in

ASCII form, the replacement value will be two

letters inside quotes; if not, it will be 3

numeric chars.

33 TIME STAMP - Replace label with a time stamp 0 that identifies time of program generation.

This can be compared at run time against the

time stamps of structures in the data

dictionary to ensure that the structures

haven't been updated since program

generation. The time stamp is 16 chars.,

formatted YYYYMMDDHHMNSSTT.

NOTE: The next eight usage classes (34-41) require both the

FROM/TO names to be structures or screens, i.e., FROM structure/TO structure and FROM screen/TO screen are valid; FROM structure/TO screen is not. They must also be used with control edit lines.

34 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5 5

INTERNAL DATA ELEMENT NAMES - Replace label

with full-qualified internal data element

names that are the same in a FROM

structure/screen (on the left) and a TO

structure/screen (on the right).

TABLE 13 (Continued) 35 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5 INTERNAL DATA ELEMENT NAMES - Same as Usage

Class 34 except the order is reversed, i.e.,

TO structure/screen on the left, FROM

structure/screen on the right. 36 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5

INTERNAL DATA ELEMENT NAMES - Replace label

with fully-qualified internal names of data

elements that use the same base elements in a

FROM structure/screen (on the left) and a TO structure/screen (on the right). 37 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5

INTERNAL BASE ELEMENT NAMES - Same as Usage

Class 36 except the order is reversed, i.e., TO structure/screen on the left; FROM

structure/screen on the right. 38 (STRUCTURE) FULLY-QUALIFED CORRESPONDING 5

INTERNAL DATA GROUP NAMES - Replace label

with fully-qualified internal group element

names that are the same in a FROM

structure/screen (on the left) and a TO

structure/screen (on the right.) 39 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5

INTERNAL DATA GROUP NAMES - Same as Usage

Class 38 except the order is reversed, i.e., TO structure/screen on the left; FROM

structure/screen on the right.

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

40 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5

INTERNAL BASE GROUP NAMES - Replace label

with fully-qualified internal names of data

groups that use the same base groups in a

FROM structure/screen (on the left) and a TO

structure/screen (on the right).

41 (STRUCTURE) FULLY-QUALIFIED CORRESPONDING 5

INTERNAL BASE GROUP NAMES - Same as Usage

Class 40 except the order is reversed, i.e., TO structure/screen on the left; FROM

structure/screen on the right.

42 (STRUCTURE) FILE TYPE - Replace label with 3 language-dependent file type: COBOL =

Relative, Sequential or Indexed; TAL = 01

(relative), 02 (sequential), or 03 (indexed).

43 (STRUCTURE) FULLY-QUALIFIED INTERNAL 3

STRUCTURE ELEMENT/GROUP NAMES - Replace label with fully-qualified internal names of all

data elements and groups within the

structure. ("Edit Control Occurs" must be

"0". )

44 (STRUCTURE) (COBOL ONLY) ALTERNATE KEY 4 4

DEPOSIT - Replace label with fully-qualified alternate key element. If alternate key can have duplicates, the "WITH DUPLICATES" clause is appended. Usually used with Selection

Class 3 in SELECT statements.

TABLE 13 (Continued) VALID

SELECTION

USAGE DESCRIPTION CLASS

45 APPLICATION NAME - Replace label with name of 3 the application the structure or screen is a

part of.

46 COPYLIB INDEX - Similar to Usage Class 9, 3 except this is used inside a COPYLIB

that is defined as a 20 in Mode1

Configuration. 3 chars.

47 (STRUCTURE/SCREEN) TOTAL ITEMS - For a 3 screen, replace label with total number of

I/O fields on the screen. For a structure,

replace label with the toal number of group

and data elements. 3 numeric chars.

48 (STRUCTURE) STRUCTURE DECLARATION - Same as 3

Usage Class 11 - without VALUE clauses. For use in SCOBOL linkages and COBOL FDs .

49 (SCREEN) DATA ELEMENT INDEX - Replace label 4 with data element's position in the screen.

50 (STRUCTURE) LOGICAL FILE NAME - Replace label 3 3 with logical, space-separated structure name (the same name that you type into the top

field of the Structure Definition service). ===============================================================

TAB LE 13 (Continued) PROCEDURE DIVISION.

SEND-SERVER-MAIN.

DISPLAY BASE SCREEN-01.

PERFORM DO-ACCEPT UNTIL EXIT-PROGRAM.

SEND-SERVER-EXIT.

EXIT PROGRAM.

DO-ACCEPT.

ACCEPT SCREEN-01 UNTIL

F001

F002

F003

ESCAPE ON SF16

(F001 THRU SF16).

PERFORM ONE OF

SEND-TO-SERVER

GET-OUT

KEY-NOT-IMPLEMENTED

DEPENDING ON TERMINATION-STATUS.

SEND-TO-SERVER.

MOVE 0 TO SEND-STATUS

MOVE TERMINATION-STATUS TO IPC MESSAGE TYPE EL

SEND PREFIX, NAME OF FILE 001

TO "SERVER NAME"

REPLY CODE 0 YIELDS PREFIX, NAME OF FTLE 001

CODE 1 YIELDS PREFIX, ERROR REPLY

ON ERROR PERFORM SEND-ERROR

* If the send was OK ...

If GOOD-SEND

...but an error happened inside the server, tell the user...

IF TERMINATION-STATUS = 2

MOVE SPACES TO WHOLE-ERROR-WINDOW

MOVE ERROR TEXT TO MSG OF ERROR-WINDOW

MOVE GUARDIAN ERROR TO GUARDIAN-ERROR OF ERROR-WINDOW

MOVE FILE STATUS TO FILE-STATUS OF ERROR-WINDOW

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01

* ...else if the send was OK and no errors occurred inside the server:

ELSE

DISPLAY SCREEN-01

MOVE SPACES TO WHOLE-ERROR-WINDOW

MOVE "BEEN THERE AND BACK," TO MSG OF ERROR-WINDOW

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01.

TABLE 14 SEND-ERROR

MOVE 1 TO SEND -STATUS .

MOVE SPACES TO WHOLE-ERROR-WINDOW.

MOVE "SEND-ERROR NUM:" TO MSG OF ERROR-WINDOW.

MOVE TERMINATION-STATUS TO TERMINATION-STAT OF ERROR-WINDOW.

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01.

GET-OUT.

MOVE 1 TO EXIT-FLAG.

KEY-NOT-IMPLEMENTED.

MOVE SPACES TO WHOLE-ERROR-WINDOW.

MOVE "THIS FUNCTION KEY NOT IMPLEMENTED." TO MSG OF ERROR-WINDOW

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01.

TABLE 14 (Continued)

SEND-ERROR.

MOVE 1 TO SEND-STATUS.

MOVE SPACES TO WHOLE-ERROR-WINDOW.

MOVE "SEND-ERROR NUM:" TO MSG OF ERROR-WINDOW.

MOVE TERMINATION-STATUS TO TERMINATION-STAT OF ERROR-WINDOW.

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01.

GET-OUT.

MOVE SPACES TO WHOLE-ERROR-WINDOW.

MOVE "THIS FUNCTION KEY NOT IMPLEMENTED." TO MSG OF ERROR-WINDOW.

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01.

MOVE 1 TO SEND-STATUS.

MOVE SPACES TO WHOLE-ERROR-WINDOW.

MOVE "SEND-ERROR NUM:" TO MSG OF ERROR-WINDOW.

MOVE TERMINATION-STATUS TO TERMINATION-STAT OF ERROR-WINDOW.

DISPLAY TEMP ERROR-WINDOW OF SCREEN-01.

TABLE 15 (Continued)

Primary Source Line ID

Source Line ID FUNCTION KEYS

#START#

10 PROGRAM ID REQUIRED

SELECTION CLASS: 2

What do you want for the name of the. program?

20 TERMINAL TYPE REQUIRED

SELECTION CLASS: 2

What type of terminal do you want this program to run on (e.g., T16-6530)?

30 NUMBER OF FUNCTIONS REQUIRED

SELECTION CLASS: 2

How many function keys do you want implemented?

40 SCREEN NAME REQUIRED

TYPE: V

SELECTION CLASS: 3

What is the name of the screen?

50 NAME OF FILE 001 REQUIRED

TYPE: S

SELECTION CLASS: 3

What is the name of the data structure?

60 ERROR REPLY REQUIRED

TYPE: S

SELECTION CLASS: 3

What do you want for your error-reply structure?

10 ERROR TEXT REQUIRED

TYPE: S

SELECTION CLASS: 4

Which element is the error text?

20 FILE STATUS REQUIRED

TYPE: S

SELECTION CLASS: 4

Which element is the file status?

30 GUARDIAN ERROR REQUIRED

TYPE: S

SELECTION CLASS: 4

Which element is the Guardian error?

TABLE 27 PREFIX REQUIRED

TYPE: S

SELECTION CLASS: 3

What do you want for the IPC prefix?

10 IPC MESSAGE TYPE EL REQUIRED TYPE: S

SELECTION CLASS: 4

Which element is the message type? SERVER NAME REQUIRED

SELECTION CLASS: 2

What is the name of the server class?

TABLE 27 (Continued)

SECTION SPECIAL-NAMES

BLINK IS BLINK,

DIM IS DIM,

HIDDEN IS HIDDEN,

PROTECTED IS PROTECTED,

REVERSE IS REVERSE,

NOBLINK IS NOBLINK,

NOTHIDDEN IS NOTHIDDEN,

NORMAL IS NORMAL,

NOREVERSE IS NOREVERSE,

NOUNDERLINE IS NOUNDERLINE,

UNPROTECTED IS UNPROTECTED,

REVDIM IS (REVERSE, DIM),

REVUND IS (REVERSE, UNDERLINE),

REVUNDNOPROTECT IS (REVERSE, UNDERLINE, UNPROTECTED),

REVUNDIM IS (REVERSE, UNDERLINE, DIM),

NOREVUND IS (NOREVERSE, NOUNDERLINE),

HIDNOREV IS (HIDDEN, NOREVERSE),

NOUNPROTECT IS (NOUNDERLINE, PROTECTED, HIDDEN),

NOREVPROTECHTHIDDEN IS (NOREVERSE, PROTECTED, HIDDEN),

NOPROTECTUND IS (UNDERLINE, UNPROTECTED, NOTHIDDEN),

NOPROTECTNOUND IS (NOUNDERLINE, UNPROTECTED, NOTHIDDEN),

PROTECTUNDIM IS (PROTECTED, UNDERLINE, DIM),

NOPROTECTNODIMUND IS (UNPROTECTTED , UNDERLINE),

NOTON IS NOTON,

NOTOFF IS NOTOFF,

TABLE 33

131

Claims

WHAT IS CLAIMED IS:

1. A method of generating a compilable computer program comprising the steps of:

(a) providing an edit file having a first portion thereof identified as modifiable with a first identifier;

(b) providng a control record said control records having a first user interface for input and a first input attribute, said first input attribute defining a manner of modifying file code based on a first input;

(c) prompting for said first input with said first interface for input;

(d) based on said first input and said first input attribute, modifying said modifiable portion of said edit file to generate a compilable computer program.

2. The method as recited in claim 1 wherein said input attribute further comprises a selection class and a usage class, said selection class defining how said identifier will be activated and said usage class defining what will happen to the identifier if it is activated.

3. The method as recited in claim 1 further comprising the step of storing the compilable computer program.

4. The method as recited in claim 3 further comprising the step of compiling said compilable computer program.

5. The method as recited in claim 4 further comprising the steps of executing said compilable computer program and obtaining output from said computer program.

6. The method as recited in claim 1 wherein the control record is independent of the edit file.

7. The method as recited in claim 1 wherein said eidt file further comprises portions thereof identified as elective with a second identifier, said elective portion associated with a second input attribute, and further comprising the steps of (a) prompting for a second input and (b) inserting a desired elective portion if said second input is an affirmative input.

8. The method as recited in claim 7 wherein said desired elective portion is a copylib module.

9. The method as recited in claim 1 wherein said step of modifying further comprises the step of inserting said user response into said edit file to replace at least a portion of said identifier.

10. The method as recited in claim 1 further comprising the step of providing a script sequence, said script sequence identifying an order of presentation for a plurality of said interface for inputs.

11. The method as recited in claim 7 wherein said elective portion is a data structure.

12. The method as recited in claim 7 wherein said elective portion is a table structure.

13. The method as recited in claim 7 wherein said elective portion is a screen.

14. The method as recited in claim 7 wherein said elective portion is a function.

15. The method as recited in claim 7, 8, 11, 12, 13, or 14 wherein said elective portion contains portions thereof identified as modifiable with a third identifier, said modifiable portion of said elective portion associated with a third input attribute, and further comprising the steps of

(a) associating at least a portion of said modifiable portion of said elective portion with a second interface for input;

(b) prompting the user with said second interface for input;

(c) based on a response by a user to said second interface for input and said third input attribute, modifying said elective portion to create compilable elective portion.

16. The method as recited in claim 1 wherein the step of modifying further comprises the step of modifying a plurality of portions in said edit file identified modifiable with said identifier.

17. The method as recited in claim 13 wherein said screen is selected by the user from a list of screens.

18. The method as recited in claim 1 wherein said step of modifying further comprises the steps of inserting a customized portion said customized portion comprising a line placed into said eidt file the number of times entered by the user in response to the user question.

19. The method as recited in claim 18 further comprising the step of incrementing a counter each time said line is dumped into said program.

20. The method as recited in claim 1 wherein said identifier occurs in a plurality of positions in said edit file.

21. The method as recited in claim 1 wherein said edit file has a subordinate portion identified as modifiable with a subordinate identifier, and further comprising the steps of

(a) associating said subordinate modifiable portion with a second user interface for input and a second input attribute, and

(b) prompting for input with second user interface if said first input activates said subordinate identifier.

22. A method of generating customized computer code comprising the steps of:

(a) providing as edit file, said edit file containing a plurality of lines identified with labels said labels identifying portions of said edit file which are elective, modifiable components, and portions of said edit file which are fixed modifiable components;

(b) associating said fixed modifiable and said elective modifiable components with a first and second user question, respectively;

(c) prompting a user with said first and said second question;

(d) based on a response by the user to said first and said second user question, inserting a custom portion into said edit file for said fixed modifiable and said elective, modifiable components, respectively.

23. The method as recited in claim 22 wherein each label is associated with a usage class and a selection class, said usage class defining what will be done to the label if it becomes active and selection class defining how the label will be made active.

24. The method as recited in claim 23 wherein said selection class requires a user to provide a specific value.

25. The method as recited in claim 23 wherein the selection class requires a user to provide a screen name.

26. The method as recited in claim 24 wherein the selection class requires a user to specify a screen and an element within the screen.

27. The method as recited in claim 23 wherein the selection class requires the user to specify a structure.

28. The method as recited in claim 23 wherein the usage class defines that the label will be replaced with a user response.

29. The method as recited in claim 23 wherein the usage class defines that the label will be replaced with a member selected from the group: data element, structure record name, copylib statement, copy statement for a copylib section, and a copylib module.

30. The method as recited in claim 23 wherein the usage class defines that the label will be treated as a counter, said counter replacing said line label and incremented each time it is dumped.

31. The method as recited in claim 33 further comprising the step of providing a script sequence, said script sequence defining an order of presenting said user questions.

32. The method as recited in claim 23 wherein at least one of said plurality of lines is subordinate to a second of said plurality of lines, said subordinate line label prompting a user only if a label in a said second of said plurality of lines is activated.

33. Apparatus for generating custom, compilable computer program comprising;

(a) means for providing an edit file, said edit file having portions thereof identified as modifiable with labels;

(b) means for providing a control record, said control record having a first user interface for input and a first input attribute, said attribute defining a manner of modifying said file based on a first input;

(c) means for prompting a user with said interface for input;

(d) means for the user to enter a response to said interface for input;

(e) means for modifying said modifiable portion based on said first input and said first input attribute.

34. Apparatus as created in claim 33 wherein said edit file further comprises portions thereof identified as elective and further comprising

(a) means for prompting a user to identify desired elective portions, and;

(b) means for inserting said desired elective portion.

35. Apparatus as recited in claim 34 wherein said desired elective portion is a copylib module.

36. Apparatus as recited in claim 35 wherein said copylib module contains portions thereof identified as modifiable and further comprising

(a) a copylib model, said copylib model associating at least a portion thereof with a copylib user question;

(b) means for prompting the user with said copylib user question, and;

(c) means for inserting a custom portion into said copylib module into said copylib module to create a custom copylib module.

37. Apparatus as recited in claim 34 further comprising a means for specifying an order of said questions.

38. Apparatus as recited in claim 34 wherein said elective portion is selected from the group:

screens, table structures, data structures, or functions.

39. Apparatus as recited in claim 34 wherein said elective portion contains modifiable portions therein and further comprising

(a) means for associating at least a portion of said modifiable portion of elective portion with a second interface for input;

(b) means for prompting a user with the second interface, and;

(c) means for, based on a response by a user to said second interface and a second input attribute, modifying said elective portion.