Autogrammer

This invention relates generally to computer programs for the storage and retrieval of information and more particularly "user-friendly" computer programs capable of automatically generating data storage and retrieval application programs.

Recently, micro-computers (defined herein as computers having word length capabilities of 16 bits or less) have flooded the home and small business market. Accompanying this surge in micro-computer sales is a corresponding demand for "user friendly" software. The ultimate goal of programmers creating the software for this personal computer market is the design of programs for the unskilled operator which that operator will be able to modify to fulfill his special needs.

Previously, the art of creating computer programs through which information could be stored and retrieved required the skill of at least one experienced programmer capable of employing a high-level machine language such as COBOL or FORTRAN. The programmer, relying on all of his skill and expertise and with the expenditure of great amounts of time was able to create a computer program tailored to satisfy one specific need. Any deviation from the initial program necessitated a complete redraft of the program.

More particularly, heretofore the person defining the program parameters first disseminated those parameters to the actual programmer who, in turn, conveyed those parameters and all accompanying documents to a systems analyst who was responsible for the design of the program. Designing a program, is a complicated process involving the use of flowcharts, parameter lists, CRT design forms, print-out design forms and the formatting of actual data base records. Also, the systems analyst was responsible for the type of data base used in the system and designed the support programs required to maintain that data base.

Having decided upon the parameters and having selected the support programs for the data base, the systems analyst then turned the design documents over to the programmer who converted these documents into the program statements which allow the computer to do the desired work. The conversion to program statements not only involve one or more complicated computer languages, but also requires exhaustive and time consuming testing and "debugging." The more complex the program becomes, the more difficult it is to eliminate inherent flaws. In fact, today's programmer spends 70% of his time reworking old programs to enable them to handle new requirements or make them work with new equipment. Thus, a big backlog of "to-be-developed" programs results.

While it is possible that the program design process could be handled by the programmer alone, it is almost always requires the cooperation of two people: the person with the need and the programmer. Often the design process involves more people. Of course, the more people involved: (1) the greater the possibility of deviating from the original request becomes; and (2) the longer the time period between the initial request and the actual creation of the program.

The need to streamline and simplify the programming process is apparent. One solution is called an "application generator." This is a standard program module, or program unit, that can be used when putting together the software, or instructions, for a complex business computer systems. In order to minimize creation time and reduce errors, the computer is allowed to create a portion of the menial and more complicated program. In fact, on the very large and sophisticated main frame computer systems using application generators, such as MARK V, exceptionally gifted programmers have created working programs in a few days. However, these programming techniques are limited to the large computers, are available only to programmers, and cost large sums of money (in the vicinity of $100,000).

As a result, the person needing the programming must be able to justify the cost involved. And in small businesses, the cost can seldom be economically justified. Most programming requests, even for a small business and on small computer systems, require large sums of money, time and manpower.

In contrast to the foregoing, the invention described herein allows a person to relate his needs directly to the computer. With information supplied by the person orginating the request, the computer creates the final computer program directly. The program creation time involves only moments, and the computer creates a more complete and sophisticated program than the heretofore conventionally created programs. Possibly most important, the person can obtain programs that, although very helpful, would have been too expensive to justify creating if it was necessary to follow the conventional creation process routine. The entire interaction between the operator and computer is handled visually and in free form mode (a mode that places few limitations on the programmer, i.e., is very unstructured), permitting the unskilled operator, a person with very little, if any, previous computer related experience to satisfy his needs within minutes.

It is therefore a principal object of the present invention to create a computer program which can be used by operators unskilled in complex computer languages to develop specific application programs.

Another object of the present invention is to develop a computer program for generating application programs for unskilled operators through the use of a technique whereby the computer develops its own internal language.

A further object of the present invention to develop a computer program for generating application programs through a visual creation process which requires no textural preparation on the operator's part, i.e., the computer allows the operator free form ability.

Yet another object of the present invention to provide an application generation program through which the computer interprets the operator's input by creating its own mini-interpretive language based upon the inputted information.

A still further object of the present invention is to create a generation program employing a validation-interpretation cross reference table by which the information specified by the operator and the textual information prepared by the operator are compared to develop a program best suited to a particular need.

Still another object of the present invention to provide an advanced automatic program generator which excels in the ease and speed of application program development.

A further object of the present invention to create a computer program for each special application rather than attempting to force special information into general purpose programs.

Another object of the present invention is to create a computer program which develops other application programs in a fraction of the time needed to create application programs by means of convention programming.

A still further object of the present invention is to provide a computer program for generating application programs which can be used by non-programmers whereby the application programs are generated from a visual display formatted directly onto the display screen.

Still another object of the present invention is to provide a generation program which develops an application program in machine language without requiring a user's input program.

A further object of the present invention is to provide an application generation program which creates application programs that run independently of other programs.

Another object of the present invention is to provide an application generation program which alleviates the need to restart the program due to operator or machine error by automatically returning to the last routine in the program if an error results.

A still further object of the present invention is to provide an application generation program which pre-empts sections of program code if the code was inadvertently accessed by another section of the program.

Yet another object of the present invention is to provide a computer program which develops other application programs capable of performing algebraic operations using floating point notation with twenty six significant digits and ten decimal places.

A further object of the present invention is to provide a computer program which develops other application programs capable of searching for and sequencing data records in a data base file more efficiently than prior art computer programs.

The present invention comprises a method of generating an application program for manipulating data on a computer including the steps of using field delimiters inputted by a user through an input-output unit connected to a computer to delineate a field. The computer uses program code to create a data base descriptor file, the descriptor file is adapted to receive and store the delimiter; and to create a data base file in a separate location, the data base file is adapted to receive and store inputted data. The computer also uses program code to create a data base key file in a separate location, the data base key file is adapted to identify the stored data; and to manipulate and transfer data between the field, the data base descriptor file, the data base file and the data base key file to generate an application program.

The present invention also comprises a method of transforming a general purpose electronic computer into a special purpose electronic computer. The computer includes a screen monitor for communicating with the computer. The screen monitor and the computer are operatively connected to a control unit for presenting data and commands to the computer. The computer also includes a storage unit for placing data in memory for subsequent retrieval and use. The method includes the steps of communicating with the control unit through a responsive sequence of operations wherein visual information is displayed to the user on the screen monitor and the user enters corresponding instructions. Spaces allocated in the stored unit for storing subsequently inputted data and the control unit is used to generate program code through which the fields may be manipulated when the user inputs instructions onto the screen monitor.

The present invention also includes an application program generator adapted for use with computers having relatively small memory storage capacities. The application program generator includes means operatively connected to the computer for inputting data to and receiving output from the computer and means adapted to store data and programming code. The application program generator also includes control means operatively connected to the input-output means and the storage means, such that the control means, the input-output means and the storage means are adapted to transfer information to and from each other individually and collectively in response to a command signal from the control means, the transfer of information pursuant to directive stored in the control means, the directives include, but are not limited to the following procedural steps: using field delimiters inputted by a user through the input-output means to delineate a field; creating a data base descriptor file in the storage means, the data base descriptor file is adapted to receive and store the delimiters; creating a data base file in a separate location, the data base file is adapted to receive and store inputted data; creating a data base key file in a separate location, the data base key file is adapted to identify the stored data; and generating an application program to manipulate and transfer data between the field, the data base descriptor file, the data base file and the data base key file.

The present invention also contemplates a method of searching a data base file structure for use with storing a new data base record on a computer having a data base file and a key file for containing data records, the method includes the step of creating a file number to attach to the end of a key file record so that the data base record corresponds to the key file record number and key value. The method also includes comparing the key record number and the data base record number and then performing a binary search to find the key value and the key record number if the difference between the numbers is greater than a predetermined value. Otherwise, the method performs a sequential search to find the key value and the key record number if the difference between the numbers is equal or less than the predetermined value. If there is no difference between the numbers being compared, the method includes identifying the closest record number in the key file.

To the accomplishment of the foregoing and still other objects and advantages, the invention, is best utilized in, a system whereby a computer is provided with the capability of internally generating program code from data inputted by a user; the program code employed by the computer to structure, store, and manipulate inputted data. The system includes an input-output unit, a storage unit, a control unit operatively connected to the input-output unit and the storage unit such that each unit is capable is communicating, individually and collectively, with all other units upon receipt of a command signal from the control unit. The system also includes means for delineating a field using field delimiters inputted by a user and means for creating a data base descriptor file in the storage unit, the descriptor file is adapted to receive and store the delimiters. Also, the system includes means for creating a data base file in the storage unit, the data base file adapted to receive and store inputted data and means for creating a data base key file in the storage unit, the key file adapted to identify the stored data. Finally, the system includes means for automatically generating program code from the control unit, whereby the fields may be manipulated through use of the screen monitor.

The invention, together with further objects and advantages thereof, can best be understood by reference to the following specification, taken in connection with the accompanying drawings, in which:

FIG. 1 is a flow chart illustrating the subroutines which combine to define the AUTOGRAM subroutine;

FIG. 2 is a flow chart illustrating the subroutines which combine to define the EDITOR subroutine;

FIG. 3 is a flow chart illustrating the subroutines which combine to define the GRAPHIC subroutine;

FIG. 4 is a flow chart illustrating the subroutines which combine to define the EDCTLE subroutine;

FIG. 5 is a flow chart illustrating the subroutines which combine to define the INAUTO subroutine;

FIG. 6 is a flow chart illustrating the subroutines which combine to define the CLRMM2 subroutine;

FIG. 7 is a flow chart illustrating the subroutines which combine to define the BRKSET subroutine;

FIG. 8 is a flow chart illustrating the subroutines which combine to define the SETBRK subroutine;

FIG. 9 is a flow chart illustrating the subroutines which combine to define the VDLINE subroutine;

FIG. 10 is a flow chart illustrating the subroutines which combine to define the DISERR subroutine;

FIG. 11 is a flow chart illustrating the subroutines which combine to define the DELAY subroutine;

FIG. 12 is a flow chart illustrating the subroutines which combine to define the BUFSET subroutine;

FIG. 13 is a flow chart illustrating the subroutines which combine to define the CLRMEM subroutine;

FIG. 14 is a flow chart illustrating the subroutines which combine to define the CLRDC1 and CLRDC2 subroutines;

FIG. 15 is a flow chart illustrating the subroutines which combine to define the INITSC subroutine;

FIG. 16 is a flow chart illustrating the subroutines which combine to define the VDCHAR subroutine;

FIG. 17 is a flow chart illustrating the subroutines which combine to define the GETIFN subroutine;

FIG. 18 is a flow chart illustrating the subroutines which combine to define the INFILN subroutine;

FIG. 19 is a flow chart illustrating the subroutines which combine to define the FNDRET subroutine;

FIG. 20 is a flow chart illustrating the subroutines which combine to define the COMFLS subroutine;

FIG. 21 is a flow chart illustrating the subroutines which combine to define the COMPL1 and COMPL2 subroutines

FIG. 22 is a flow chart illustrating the subroutines which combine to define the PRISDM and PRIDDM subroutines;

FIG. 23 is a flow chart illustrating the subroutines which combine to define the GETOFN subroutine;

FIG. 24 is a flow chart illustrating the subroutines which combine to define the KBINIT subroutine;

FIG. 25 is a flow chart illustrating the subroutines which combine to define the CLR24 subroutine;

FIG. 26 is a flow chart illustrating the subroutines which combine to define the VDGRAF subroutine;

FIG. 27 is a flow chart illustrating the subroutines which combine to define the CLRDL1 subroutine;

FIG. 28 is a flow chart illustrating the subroutines which combine to define the SAVCUR subroutine;

FIG. 29 is a flow chart illustrating the subroutines which combine to define the VDREAD subroutine;

FIG. 30 is a flow chart illustrating the subroutines which combine to define the CLRPRT subroutine;

FIG. 31 is a flow chart illustrating the subroutines which combine to define the RESCUR subroutine;

FIG. 32 is a flow chart illustrating the subroutines which combine to define the GCURSR subroutine;

FIG. 33 is a flow chart illustrating the subroutines which combine to define the KBCHAR subroutine;

FIG. 34 is a flow chart illustrating the subroutines which combine to define the LOOKUP subroutine;

FIG. 35 is a flow chart illustrating the subroutines which combine to define the PRTEHS subroutine;

FIG. 36 is a flow chart illustrating the subroutines which combine to define the RAMVID and VIDRAM subroutines;

FIG. 37 is a flow chart illustrating the subroutines which combine to define the DELCHR subroutine;

FIG. 38 is a flow chart illustrating the subroutines which combine to define the SDGRAF subroutine;

FIG. 39 is a flow chart illustrating the subroutines which combine to define the INSCHR subroutine;

FIG. 40 is a flow chart illustrating the subroutines which combine to define the INLINE DELINE subroutines;

FIG. 41 is a flow chart illustrating the subroutines which combine to define the DIVIDE and MLTPLY subroutines;

FIG. 42 is a flow chart illustrating the subroutines which combine to define the CENTER subroutine;

FIG. 43 is a flow chart illustrating the subroutines which combine to define the SEARCH subroutine;

FIG. 44 is a flow chart illustrating the subroutines which combine to define the UNSEAR subroutine;

FIG. 45 is a flow chart illustrating the subroutines which combine to define the SDATAD subroutine;

FIG. 46 is a flow chart illustrating the subroutines which combine to define the SCNPRT subroutine;

FIG. 47 is a flow chart illustrating the subroutines which combine to define the OPEN subroutine;

FIG. 48 is a flow chart illustrating the subroutines which combine to define the WRITNX subroutine;

FIG. 49 is a flow chart illustrating the subroutines which combine to define the CLOSE subroutine;

FIG. 50 is a flow chart illustrating the subroutines which combine to define the ENDRR5/ENDROO subroutines;

FIG. 51 is a flow chart illustrating the subroutines which combine to define the SAVL24 subroutine;

FIG. 52 is a flow chart illustrating the subroutines which combine to define the INCHAR subroutine;

FIG. 53 is a flow chart illustrating the subroutines which combine to define the RESL24 subroutine;

FIG. 54 is a flow chart illustrating the subroutines which combine to define the FNDFLD subroutine;

FIG. 55 is a flow chart illustrating the subroutines which combine to define the FLDVAL subroutine;

FIG. 56 is a flow chart illustrating the subroutines which combine to define the FNDFLC subroutine;

FIG. 57 is a flow chart illustrating the subroutines which combine to define the REVFLD subroutine;

FIG. 58 is a flow chart illustrating the subroutines which combine to define the INPVAL subroutine;

FIG. 59 is a flow chart illustrating the subroutines which combine to define the DISMSG subroutine;

FIG. 60 is a flow chart illustrating the subroutines which combine to define the CURSON subroutine;

FIG. 61 is a flow chart illustrating the subroutines which combine to define the PRVLST subroutine;

FIG. 62 is a flow chart illustrating the subroutines which combine to define the GVAL subroutine;

FIG. 63 is a flow chart illustrating the subroutines which combine to define the CHKVAL subroutine;

FIG. 64 is a flow chart illustrating the subroutines which combine to define the PRTMSG subroutine;

FIG. 65 is a flow chart illustrating the subroutines which combine to define the DISPVL subroutine;

FIG. 66 is a flow chart illustrating the subroutines which combine to define the CRTDBS subroutine;

FIG. 67 is a flow chart illustrating the subroutines which combine to define the CRTKYF subroutine;

FIG. 68 is a flow chart illustrating the subroutines which combine to define the BINHEX subroutine;

FIG. 69 is a flow chart illustrating the subroutines which combine to define the MOVDP3 subroutine;

FIG. 70 is a flow chart illustrating the subroutines which combine to define the PERMSG subroutine;

FIG. 71 is a flow chart illustrating the subroutines which combine to define the FNDEDP subroutine;

FIG. 72 is a flow chart illustrating the subroutines which combine to define the SETSCR subroutine;

FIG. 73 is a flow chart illustrating the subroutines which combine to define the SNGRAF subroutine;

FIG. 74 is a flow chart illustrating the subroutines which combine to define the INITAP subroutine;

FIG. 75 is a flow chart illustrating the subroutines which combine to define the PRTSGN subroutine;

FIG. 76 is a flow chart illustrating the subroutines which combine to define the FLDCB1 and FLDCB2 subroutines;

FIG. 77 is a flow chart illustrating the subroutines which combine to define the TRNTTL subroutine;

FIG. 78 is a flow chart illustrating the subroutines which combine to define the DELNPT subroutine;

FIG. 79 is a flow chart illustrating the subroutines which combine to define the SETKYL subroutine;

FIG. 80 is a flow chart illustrating the subroutines which combine to define the DIRRD2 subroutine;

FIG. 81 is a flow chart illustrating the subroutines which combine to define the LOCATE subroutine;

FIG. 82 is a flow chart illustrating the subroutines which combine to define the PRMENU subroutine;

FIG. 83 is a flow chart illustrating the subroutines which combine to define the PRTTIT subroutine;

FIG. 84 is a flow chart illustrating the subroutines which combine to define the ADDREC subroutine;

FIG. 85 is a flow chart illustrating the subroutines which combine to define the SETTIT subroutine;

FIG. 86 is a flow chart illustrating the subroutines which combine to define the ARAMVD subroutine;

FIG. 87 is a flow chart illustrating the subroutines which combine to define the INLOOP subroutine;

FIG. 88 is a flow chart illustrating the subroutines which combine to define the GETINP subroutine;

FIG. 89 is a flow chart illustrating the subroutines which combine to define the PREVAL subroutine;

FIG. 90 is a flow chart illustrating the subroutines which combine to define the VALFLD subroutine;

FIG. 91 is a flow chart illustrating the subroutines which combine to define the LASTFN subroutine;

FIG. 92 is a flow chart illustrating the subroutines which combine to define the PVALDV subroutine;

FIG. 93 is a flow chart illustrating the subroutines which combine to define the LOCINT subroutine;

FIG. 94 is a flow chart illustrating the subroutines which combine to define the PVALVN subroutine;

FIG. 95 is a flow chart illustrating the subroutines which combine to define the GETFLD subroutine;

FIG. 96 is a flow chart illustrating the subroutines which combine to define the MOVRGT subroutine;

FIG. 97 is a flow chart illustrating the subroutines which combine to define the PVALD2 subroutine;

FIG. 98 is a flow chart illustrating the subroutines which combine to define the PVALLJ subroutine;

FIG. 99 is a flow chart illustrating the subroutines which combine to define the LJFLD subroutine;

FIG. 100 is a flow chart illustrating the subroutines which combine to define the MOVLFT subroutine;

FIG. 101 is a flow chart illustrating the subroutines which combine to define the PVTFLD subroutine;

FIG. 102 is a flow chart illustrating the subroutines which combine to define the PVALRJ subroutine;

FIG. 103 is a flow chart illustrating the subroutines which combine to define the RJFLD subroutine;

FIG. 104 is a flow chart illustrating the subroutines which combine to define the RETCMD subroutine;

FIG. 105 is a flow chart illustrating the subroutines which combine to define the CORFLD subroutine;

FIG. 106 is a flow chart illustrating the subroutines which combine to define the PVALKF subroutine;

FIG. 107 is a flow chart illustrating the subroutines which combine to define the LOCFLD subroutine;

FIG. 108 is a flow chart illustrating the subroutines which combine to define the LOCTKN subroutine;

FIG. 109 is a flow chart illustrating the subroutines which combine to define the TRNFBF subroutine;

FIG. 110 is a flow chart illustrating the subroutines which combine to define the TRNABF subroutine;

FIG. 111 is a flow chart illustrating the subroutines which combine to define the SAVEOP subroutine;

FIG. 112 is a flow chart illustrating the subroutines which combine to define the CHKOVF subroutine;

FIG. 113 is a flow chart illustrating the subroutines which combine to define the MSUB, MADD, MDIV, and MMUL subroutines;

FIG. 114 is a flow chart illustrating the subroutines which combine to define the PREP subroutine;

FIG. 115 is a flow chart illustrating the subroutines which combine to define the CLRFPN subroutine;

FIG. 116 is a flow chart illustrating the subroutines which combine to define the FPIN subroutine;

FIG. 117 is a flow chart illustrating the subroutines which combine to define the CLEAR subroutine;

FIG. 118 is a flow chart illustrating the subroutines which combine to define the ASCDC subroutine;

FIG. 119 is a flow chart illustrating the subroutines which combine to define the FIXE subroutine;

FIG. 120 is a flow chart illustrating the subroutines which combine to define the CHKPN subroutine;

FIG. 121 is a flow chart illustrating the subroutines which combine to define the VCOPY subroutine;

FIG. 122 is a flow chart illustrating the subroutines which combine to define the CLRBUF subroutine;

FIG. 123 is a flow chart illustrating the subroutines which combine to define the FPDIV subroutine;

FIG. 124 is a flow chart illustrating the subroutines which combine to define the LOAD subroutine;

FIG. 125 is a flow chart illustrating the subroutines which combine to define the XXADD subroutine;

FIG. 126 is a flow chart illustrating the subroutines which combine to define the LEFT subroutine;

FIG. 127 is a flow chart illustrating the subroutines which combine to define the STORE subroutine;

FIG. 128 is a flow chart illustrating the subroutines which combine to define the FPSUB, Sm and FPADD subroutines;

FIG. 129 is a flow chart illustrating the subroutines which combine to define the EXPCK subroutine;

FIG. 130 is a flow chart illustrating the subroutines which combine to define the XXSUB subroutine;

FIG. 131 is a flow chart illustrating the subroutines which combine to define the FPMUL subroutine;

FIG. 132 is a flow chart illustrating the subroutines which combine to define the RIGHT subroutine;

FIG. 133 is a flow chart illustrating the subroutines which combine to define the FPOUT subroutine;

FIG. 134 is a flow chart illustrating the subroutines which combine to define the ROUND subroutine;

FIG. 135 is a flow chart illustrating the subroutines which combine to define the CLEAN subroutine;

FIG. 136 is a flow chart illustrating the subroutines which combine to define the XFERB3 subroutine;

FIG. 137 is a flow chart illustrating the subroutines which combine to define the CONV subroutine;

FIG. 138 is a flow chart illustrating the subroutines which combine to define the MAPDI subroutine;

FIG. 139 is a flow chart illustrating the subroutines which combine to define the VIDKEY subroutine;

FIG. 140 is a flow chart illustrating the subroutines which combine to define the READNX subroutine;

FIG. 141 is a flow chart illustrating the subroutines which combine to define the KBLINE subroutine;

FIG. 142 is a flow chart illustrating the subroutines which combine to define the TRNREC subroutine;

FIG. 143 is a flow chart illustrating the subroutines which combine to define the CHKSAV subroutine;

FIG. 144 is a flow chart illustrating the subroutines which combine to define the TRNFLD subroutine;

FIG. 145 is a flow chart illustrating the subroutines which combine to define the SAVREC subroutine;

FIG. 146 is a flow chart illustrating the subroutines which combine to define the CREKEY subroutine;

FIG. 147 is a flow chart illustrating the subroutines which combine to define the TRNKYI subroutine;

FIG. 148 is a flow chart illustrating the subroutines which combine to define the COMKEY subroutine;

FIG. 149 is a flow chart illustrating the subroutines which combine to define the MKRBI subroutine;

FIG. 150 is a flow chart illustrating the subroutines which combine to define the MB1B2 subroutine;

FIG. 151 is a flow chart illustrating the subroutines which combine to define the MB2KR subroutine;

FIG. 152 is a flow chart illustrating the subroutines which combine to define the COMM subroutine;

FIG. 153 is a flow chart illustrating the subroutines which combines to define the FLMIDR subroutine;

FIG. 154 is a flow chart illustrating the subroutines which combine to define the DIVHL subroutine;

FIG. 155 is a flow chart illustrating the subroutines which combine to define the FHMIDR subroutine;

FIG. 156 is a flow chart illustrating the subroutines which combine to define the DELREC subroutine;

FIG. 157 is a flow chart illustrating the subroutines which combine to define the INKEYI subroutine;

FIG. 158 is a flow chart illustrating the subroutines which combine to define the RDNREC subroutine;

FIG. 159 is a flow chart illustrating the subroutines which combine to define the DEDMSG subroutine;

FIG. 160 is a flow chart illustrating the subroutines which combine to define the NIDREC subroutine;

FIG. 161 is a flow chart illustrating the subroutines which combine to define the RDPREC subroutine;

FIG. 162 is a flow chart illustrating the subroutines which combine to define the FNDREC subroutine;

FIG. 163 is a flow chart illustrating the subroutines which combine to define the TRNRVD subroutine;

FIG. 164 is a flow chart illustrating the subroutines which combine to define the DISREC subroutine;

FIG. 165 is a flow chart illustrating the subroutines which combine to define the RECCOM subroutine;

FIG. 166 is a flow chart illustrating the subroutines which combine to define the VALFI subroutine;

FIG. 167 is a flow chart illustrating the subroutines which combine to define the CFINTP subroutine;

FIG. 168 is a flow chart illustrating the subroutines which combine to define the DVINTP subroutine;

FIG. 169 is a flow chart illustrating the subroutines which combine to define the INSTKN subroutine;

FIG. 170 is a flow chart illustrating the subroutines which combine to define the INTPOA subroutine;

FIG. 171 is a flow chart illustrating the subroutines which combine to define the INTPFA subroutine;

FIG. 172 is a flow chart illustrating the subroutines which combine to define the INTPOP subroutine;

FIG. 173 is a flow chart illustrating the subroutines which combine to define the CHKIAV subroutine;

FIG. 174 is a flow chart illustrating the subroutines which combine to define the INSEOV subroutine;

FIG. 175 is a flow chart illustrating the subroutines which combine to define the IBSCN subroutine;

FIG. 176 is a flow chart illustrating the subroutines which combine to define the PVALCF subroutine;

FIG. 177 is a flow chart illustrating the subroutines which combine to define the PVALDC subroutine;

FIG. 178 is a flow chart illustrating the subroutines which combine to define the PVALNV subroutine;

FIG. 179 is a flow chart illustrating the subroutines which combine to define the PVALVF subroutine;

FIG. 180 is a flow chart illustrating the subroutines which combine to define the PVALD2 subroutine;

FIG. 181 is a flow chart illustrating the subroutines which combine to define the PVALPW subroutine;

FIG. 182 is a flow chart illustrating the subroutines which combine to define the PVALR6 subroutine;

FIG. 183 is a flow chart illustrating the subroutines which combine to define the PVALKF subroutine;

FIG. 184 is a flow chart illustrating the subroutines which combine to define the PVAL subroutines;

FIG. 185 is a flow chart illustrating the subroutines which combine to define the FNDVAL subroutines.

The disclosure which follows will initially describe the application program generator and then describe the automatically generated application program. This program generator is essentially a dispatch which relies upon a lengthy set of initiate specific action. The editor mode, see FIG. 2, contains a loop whereby one of a plurality of functions can be performed after which there is a return for performing additional editing type functions. The graphics mode, see FIG. 3, contains a double loop. Each loop is programmed to return to the editor mode regardless of the routine instituted. The first loop involves control functions for performing tasks such as inserting and deleting characters. The second loop involves translation and processing functions for the information inputted. The question of which loop is to be used to perform a certain function is controlled in the graphics or character mode by an internal table is scanned to identify the character and hence the proper loop routine. Once the loop is selected, the program acts in accordance with instructions received from sub-function of the editor mode. When the EDCTLG is inputted, GRINT appears and the routine continues at H and L which accesses the table to one of the graphic subroutines. If EDCTLG is again inputted, the computer returns to the editor mode. So there is a double loop interacting which only displays information on the screen.

No complex actions relative to program generation occur until the editor control, DCTLE, see FIG. 4, is inputted. Upon inputting EDCTLE, the actual program generation process is instituted. FIG. 4 presents the actual creation process from start to finish. In this creation process, the program enters the field check mode, FLDCHK, which basically validates the inputted information now displayed on the screen. In fact, a key advantage of the automatic programming generator, described herein, is to insure that all inputted information is validated prior to processing.

Once the foregoing has been completed, the program branches to EDITOR and FLD99, from which point it flows through the second and third stages of program generation. The second stage is the information validation branch, INFVAL, through which field validations are inputted in correct locations. The program next specifies the type of data which can be placed into those valid fields. The third stage of program generation is called ENDAUT, and it terminates the loop and determines the size of the program. The last stage amounts to simple housekeeping maneuvers prior to dumping the generated application program off on a disk.

As field mode is entered, the computer first performs some housekeeping functions and then flows into one of the most commonly used subroutines, FNDFLC. This is the subroutine employed to (1) retrieve information previously on the screen; and (2) begin the creation of parameters (the length of the fields, the location of the fields, the starting position of the fields on the screen). All of these parameters are completed by AUTOGRAMMER without further operator input. The progress of the program may be monitored on the screen because the field which the program is completing is highlighted in reverse video. The program, however, operates so quickly and efficiently that, while the operator perceives the gist of the computation, he is unable to appreciate the individual steps through which the program builds the parameters.

The INPVAL subroutine includes a loop adapted to display a message on the screen informing the operator of the total number of possible input validations. By depressing the F1 key, the message is displayed. The program determines the number of validations previously inputted, the nature of those validations, whether the operator committed an error by inputting contradictory validations, whether the validations are indeed valid, and finally, informs the operator of the existence and nature of any operator committed errors. Once a given field is completed, the program acknowledges the validity thereof and proceeds through another subroutine TRNVAL adapted to reverify all the information that was inputted and then transfer it into a table contained within the application program. This second validation is necessary to eliminate the possibility of inputting contradictory validations. Each validation might be individually proper, but two of the parameters taken in combination might contradict one another.

When the program flows to the point marked GETVAL, it may proceed to MAXVAL which is a routine indicating the maximum number of validations have been exceeded and the computer is therefore terminating the validation table and informing the operator that a particular field is completed. However, if the maximum number of validations has not been completed, the screen displays a message that it is adding the input to the validation list and reprinting the list to include all inputted validations. The program then reaches PRVLST which is a subroutine adapted to display the updated list of validations, locate the position of the cursor and reset the cursor. Finally, the GVAL subroutine may be employed to retrieve another validation.

At this point, it is possible that the maximum number of validations has again been reached, so the program moves to TRNVAL. If the maximum has not been exceeded, the program proceeds to GETVA3 which checks the quality of the validation and displays an error message if the validation is improper, delays the message for a sufficent period of time for the operator to read it, clears the screen, and restarts the loop. If the validation was proper, the computer proceeds to SETVAL which fixes that validation as part of the validation table and returns to retrieve the next validation, etc. The computer will remain in this loop until it acts on all the inputted information which has been arbitrarily set at a maximum of twenty validations, some of which are contradictory, if taken in combination. AUTOGRAMMER eliminates possible errors prior to creating the application program by not permitting the entry of contradictory or invalid validations. When the operator desires to correct the field, it is placed into memory, the cursor is returned, the validation display screen is cleared, the next field is retrieved and highlighted in reverse video, another set of input validations are retrieved, the display is again reverse highlighted to return it to the normal condition, and the program loops thereabout until all input validations have been completed. The object of using a highlighted field to inform the operator which field is being processed, rather than the numbering of fields as is commonly done in other programs, is to allow the operator possessing little computer programming knowledge to operate the program. When all fields have been validated, the program moves to the TRNVAL subroutine.

It should be noted that most of the names applied to the routines are meant to connote their function. TRNVAL, meaning transfer validations, includes a subroutine TRNVA5. The suffix "5" indicates an early location in the program. Another subroutine of TRNVAL is TRNV99 wherein the suffix "99" signifies the last location in the routine. After the 99 subroutine is completed, another routine will be called. Intermediate numbers are used when the mid-point of the routine is entered. The higher the number, the closer to the end; the lower the number, the closer to the beginning.

Note further, when the program enters a field validation routine, it encounters different classes of validations; interpretive validations and absolute validations. Absolute validations, such as left justify, are accepted by the program without further operator input. However, interpretive validations, such as computed field values, requires further information. The program uses the INLOOP subroutine to obtain that information i.e. field specifications or the location of field validations. In summary, the program first obtains all validations. Absolute validations are processed immediately. The program returns for more information with interpretive validations.

All validations are checked in the most expeditious and efficient manner. For instance, interpretive validations are first tested on a byte-by-byte basis. If the whole byte is found to be valid, then it is possible to proceed to test the next byte. Only if the byte test returns with an invalid response is it necessary to check the information on a bit-by-bit basis.

As the program completes a field validation, all of the information inputted by the operator is displayed on the screen. Validating a field means (1) the parameters have been determined to be proper; and (2) the operator has supplied the necessary information about the scope of the field. The program then flows into a data base creation routine, CRTDBS, which simply clears the bottom line of the screen, locates the name given to that data base at the beginning of the program, completes the parameter list, and opens and closes the file. Essentially then, the program obtains all the information that was previously inputted relative to the number of fields and the total length of the fields then adds that information to the parameter list. Note that this does not imply that the program is actually placing anything in the data base, it is merely allocating space for records which will be inputted into the data base later.

The program is now able to create a key file which involves basically the same process as was used to create the data base. The only difference is that the length of the first field in the key file determines the length of that key file (actually the length of the first field plus two bytes is the length of the key file because two bytes are used for a pointer). At this point, the message "creating application" is printed. The computer proceeds into a BINHEX subroutine which converts numbers from binary to hexidecimal. The subroutine ENDAUT computes the size of the program based upon the validations and upon the known length of the subroutines. The result is a binary number for the beginning and the end of the field. The difference between the beginning and ending values is converted from a binary to a hexidecimal value which the operating system can understand.

ENDAU9 essentially determines where AUTOGRAM started, where it is to go at the end of the screen, changes old memory to zeros and issues a return command. Finally, the computer moves to ENDCRE which returns to the operating system so that, for security, no trace of the program remains.

SInce the application program opens a data base and a key file, it is important that the break key operates exactly as desired. Whereas, the generation program uses the break key to halt a routine; depressing the break key with the application program running will cause trouble. While two files are opened, two control blocks are simultaneously instituted to prepare the key file and the data base file. A security analysis is also completed prior to reaching the screen menu.

The screen menu displays a choice of five functions for operator selection: (1) end the current search; (2) display a record; (3) modify a record; (4) delete a record; or (5) add a record. Each of these menu functions has its own loop of subroutines. For instance, the program for adding a record contains the following subroutines: VDCHAR sets the cursor location; SETSCR saves the bottom line of the screen for system error messages; PRTMES prints a message stating the serial number, the operator generating the program, and the copyright notice; CLRDC1 clears a section of memory for transferring the data base and the key file to and from the disk; FLDCD1 is a block for storing data that is not as yet ready to go into the previous memory. Whereas, the previous section of memory is controlled by this program and can be transferred from place to place. Continuing with the "adding" program, FNDRET locates the end of the names that are employed in the next routine and the parameter list is completed with the names for the key and data base files. The subroutine for transferring titles will take a previously created title and put it onto the screen descriptor and into memory. At this point, prompted fields and non-prompted fields have been created. Prompted fields are displayed, while non-prompted fields are not displayed until the application program is finalized.

By doing a read routine without paying attention to errors in the data base file, it is possible to determine the number of records contained therein. The routine is used to read the last record in the file; a locate subroutine determines the actual numerical value of the last record; CLRMM2 clears out space in the buffer memory; a delay subroutine provides sufficient time for the operator to read the sign-on message; and finally, the cursor is replaced. The menu items are then redisplayed and the input of a number, selects one of the five possible menu items.

In summary, ADDREC may be called to take the previously created RAM image, print the title, obtain information based upon the parameter list, clear the sreen after the display has been filled with information, return, replace that screen with a blank screen, and loop to the start of the subroutine for additional information. It is important to note that this relates to non-data base programs.

If a data base or key file has been created, a loop with essentially the same routine as previously described for the non-data base type programs is followed. The only difference arises if there is difficulty with the inputted data. The program will return and request that the operator retype the data. Otherwise, all the data on the screen is transferred to the field memory buffers and the subroutine SAVREC transfers the data on the screen to the buffer memory.

By depressing the escape key, the operator may perform one of the other menu functions. When the program accesses the INLOOP subroutine, it remains in that subroutine until the operator enters the escape command. Therefore, another function cannot be selected until the escape is initiated.

After ADDREC, the operator may decide to delete a record by moving to the second function on the menu, DELREC. The DELREC subroutine first sets the title, transfers the title to the screen, and obtains input for the key record of the first field on the screen. If the operator decides to escape because he actually did not want to delete a record, the program returns to the menu display. Otherwise, the program proceeds to DELRE3. In DELRE3 the scroll is set, a message is printed on the bottom part of the screen which asks whether the operator actually desires to delete that particular record. The response to this question must be yes or no. If a no answer is received, the computer moves out of the DELRE3 loop.

Even if a yes answer is received, the program requires a second affirmative response in order to actually delete the record. Obviously, this is a fail safe measure to insure no records are accidentally removed. If the second response answer is no, it returns and routes through the loop once again with another record. If the second answer is yes, the record is erased and the program returns to the start of the loop to determine whether it is desired to delete further records.

When the DELREC subroutine requests a response, the operator has three choices: (1) yes, the record identified on the screen is the one to be deleted; or (2) no, that is not the record that should be deleted; (3) no, the record is not the correct one, however, the one next to it may be the one that should be deleted. Therefore, the option exists of continuing the DELREC routine with the next record or the previous record.

The next menu function, MODREC, provides the operator with the ability to modify a record. Once again, the title and data is transferred to the screen. Then several options exist. The operator may abort the function, modify the previous record, or modify the next record. If the present record is the one to be modified, FNDREC locates the record. The program then accesses MODRE7 and INLOP5. Note that the INLOP5 branch does not allow the first field to be modified because that is the key field and the key field can only be modified by deleting the record. The exit point from MODREC is the abort sequence DSMENU. FNDREC is a self-contained subroutine which attempts to locate a specific record. If the record cannot be located, a message is displayed or a flag is set. When the program returns, at the end of the routine, it views the flags. If the flag is an error flag, the program will return to the beginning. If something is wrong, the program will select the correct error message.

Another menu function is the subroutine DISREC which displays a record. Again, the title is set and transferred to the screen. The subroutine obtains a key value from the INKEY subroutine. Depending on the input when the cursor is in its initial position, several possibilities exist: (1) a previous record may be displayed; (2) the next record may be displayed; (3) the display may be printed; (4) the menu may be returned; and (5) the data may be entered. If the data is to be entered, FNDREC requires the key file to be keyed in. The program proceeds through the subroutine where it finds the value in the key file, displays the value, locates the record and returns to DISRE5. The last file number is checked to determine if the maximum allowed number of files has been exceeded. If so, the appropriate message is displayed. If the first field was inputted and the operator desires to proceed, the arrow key is depressed and the program proceeds with the remainder of the data excepting the first field.

For a non-key field search it is necessary to clear more memory, transfer the record, read the next record, locate and display the record, possibly display an error (not located) message, compare the data to determine the similarity thereof, and finally, return to DISRE9 wherein the actual record is transferred to the screen. The program flows to branch to DISRE4 where additional information may be inputted and other records may be searched. However, if the search has been completed, there is a return to DISRE4. This means that all the information inputted in INLOP5 will be applied to the program to the next logical record that meets the requirements. If the operator desires to continue with the next record, the program will compare the records to the requirements, determine whether they are identical and print error messages if necessary. If the comparison is positive, the program proceeds to DISRE9 and transfers the record to the screen. If the comparison is negative, the program returns after displaying a message that the next record is incorrect. The option also exists of proceeding with adjacent records. If the present record, the previous record and the next record do not compare, the operator may search for a new key value by depressing the escape key.

At this point, the option exists of depressing a return or arrow key. If the return key is depressed, a key search is initiated; if carriage return is hit, the program proceeds to DISRE7 which locates the absolute record that was inputted at INKEY1 and returns. If the arrow key was depressed, the last field number is checked to be sure that the maximum number of fields has not been exceeded. Then END99 closes the data base and the key file. ENDCRE clears the screen, retrieves the current break factors and executes the supervisory command RST8 which returns to the system.

The foregoing is basically a description of the manner in which the application program is generated. These subroutines enable the generated application programs to stand alone. In other words, the AUTOGRAMMER allows even unskilled operator to write a program which accomplishes the operator's desires based upon (1) the data entered by the operator; and (2) the design graphics displayed by the operator on the screen. It differs from the commonly available generation routines which use thousands of BASIC subroutines, ask the operator a multitude of questions, and based upon the answers thereto, takes certain routines and patches them together. No new code is created. A simple recombination occurs. The final result of that type of generation technique is an aggregation of subroutines which must be used under the contol of a BASIC program. Furthermore, the aggregation of subroutines rarely fullfills the operator's wishes and never accomplishes the operator's desired goal in an efficient manner.

Moreover, these generation programs actually fail to generate a program. They merely recombine the internal subroutines of the basic program in combination with some data tables. These types of program generation schemes are more aptly denominated "program reorganizers." In contrast thereto, the operator does not talk to the computer in the present invention. The operator merely supplies the computer the name of the program to be created and the same information he otherwise would provide a programmer writing a program. The operator uses no syntax. AUTOGRAMMER commands the computer to scan the information displayed on the screen and analyze it. For instance, once the beginning of the field has been marked, AUTOGRAMMER views the field and locates the end. Then AUTOGRAMMER calculates the distance between the characters, creates the necessary field length internally, moves the cursor to that location, inputs data on a character-by-character basis until the end of the field is reached, takes the field, and transfers that field without any operator input. It's completely syntax free from the operator's standpoint. The only questions that must be answered by the operator are the validations.

As an example, suppose the operator is working in a bank. A customer enters to borrow some money and a re-payment schedule must be calculated. With previous program generators, in order to perform this calculation, the banker would have to command the computer: "Go to field number 22 which is equal to field number 16 times field 12." The banker would therefore be required to know what the field values are, the location of the field as well as the field number. In contrast thereto, with the program described in the instant application, the operator merely uses the cursor control to graphically display a field and the program then locates that field. The operator indicates the computed field and the field is highlighted in reverse video. The program requests: "Do you want an absolute number of field?" the operator might reply: "Field." The program returns to the beginning and displays a message as to the field number. The operator informs AUTOGRAMMER of the particular field without reference to a numerical value and the program then requests the type of function to be carried out with that field. The operator may say: "Add." AUTOGRAMMER performs the addition. The syntax free operation of AUTOGRAMMER places it generations ahead of even the most expensive and sophisticated generation programs available for main frames.

Perhaps the most advanced of those generation programs is the MARK V. It is not designed for the business user, but for programmers possessing knowledge of high level syntax. The generation programs function more as a compiler using a basic predesigned program and changing the language into machine language. Rather than writing a program, the generation programs merely convert the basic program to machine language to form an independent program. The programmer actually writes the program.

Another disadvantage is that these program generators are language driven. The operator must learn the language and its syntax. On the other hand, AUTOGRAMMER uses a visual creation process with no textual preparation. Rather than guiding the operator down a narrow path with a question and answer format, AUTOGRAMMER allows the operator the ability to freely form a program design through visual orientation. With AUTOGRAMMER, the computer interprets the operator's visual rather than textual input.

Additionally, there are some programs that generate interpreting code. These computers generate a basic program, but that program is only a subroutine based upon the high-level syntax of an operator. Instead of compiling the subroutines into machine language, another program called BASIC reads and executes the lines of code sequentially, thereby interpreting the subroutines as it progresses through the program. In contrast thereto, a compiler reads all of the code and converts it to machine language. Then an interpreter reads and executes on a line-by-line basis. These techniques are a stark contrast to AUTOGRAMMER which actually creates a stand alone program to efficiently manage the inputted data.

Another problem with program generation is that most micro-computers have a memory limited to about 64K. The so-called program generators use a module that may take up 30K. Thus, the biggest program it can generate is 34K. When a program generator must use a BASIC program and a BASIC interpreter, the computer quickly runs out of memory to handle the generated program. In contrast thereto, AUTOGRAMMER generates a machine language program that is very small, totally self-contained, with operator control only needed to input information. AUTOGRAMMER requires about 42K of memory. The application program generated by AUTOGRAMMER, although it may vary in length, usually only requires about 20K to 24K. The part of the program that needs the most memory is the math package. Using the add, subtract, multiply and divide functions for numerous fields contained in a data base and key file will result in a relatively large application program (up to 24K or 26K). If no data base is used, however, a math package is not needed and the generated application program may be as small as 10K.

Perhaps the most unique portion of AUTOGRAMMER is its ability to construct a language internally. Since AUTOGRAMMER does not require the language or syntax of the operator, it must have the internal ability to generate routines to meet the operator's needs. Therefore, it constructs a language internally which is primarily table driven using its own parameters. Initially, the table is totally blank. It stores bits and pieces of information and then internally interprets and executes the inputted information depending on the requirements of the operator. There are several large sections of memory which are cleared and then the information keyed in will vary depending upon the application of the program.

Based on the foregoing, there can be no doubt that the concept of a machine generated application program requiring no operator syntax is very desirable. The present invention therefore describes the first truly computer generated application program capable of use even with micro-computers.

Now that the major subroutines and general objects of the instant program have been highlighted, the following detailed description of the flow charts and individual subroutines will allow the reader to appreciate the truly innovative nature of the present invention.

Referring now to FIG. 1, the automatic application generating routine, also referred to herein as AUTOGRAM, will be described in detail. It should be noted that the specific program language is appended hereto as Appendix A. This particular embodiment of the present invention is ready for use on commercially available Radio Shack TRS series micro-computers. It should be understood that the present invention contemplates being used on computers of all sizes and brands. A person of ordinary skill in the art can modify the present invention to take into account the differences in firmware between computers. The object of the following discussion is not to repeat every step of the program found in Appendix A, a lengthy task considering the number of program commands. Instead, an understanding of the present invention is more readily promoted by a general description of the routines and subroutines necessary to appreciate (1) the logical progression of those program commands; and (2) the intricacies and scope of the present invention.

With the foregoing in mind, the automatic application generating routine begins with the relatively short subroutine INAUTO, see FIG. 5, in which the computer is told to clear memory, CLRMM2, see FIG. 6, and then return to AUTOGRAM through RETURN. The next subroutine of AUTOGRAM is BRKSET, see FIG. 7, which performs two successive functions, each termed SETBRK. The first SETBRK routine retrieves the computer-stored break routine and the second SETBRK institutes a new break routine. In other words, the old break routine is found, saved and changed so as to form compatible with the internal language used by the generating program. SETBRK, see FIG. 8, consists of a RST8 command and a RETURN command.

The RST8 command is a basic computer-related supervisory call. By way of explanation, every computer contains software which controls its particular hardware. In order for a program to control the hardware of a computer, it is necessary to establish communication with the supervisory call, referred to herein as RST8, which will then translate the programmed computer commands to a hardware level for accessing the disk drive, etc. For example, in the BRKSET subroutine, the supervisor is first asked how it normally processes the break key. Then it is commanded to process the break key in a different and preferred manner. As a result, the computer no longer responds as originally programmed when the break key is pressed, but rather, control of the supervisory function for the break key has been appropriated by the instant program.

The next subroutine of AUTOGRAM is VDLINE, see FIG. 9, which is another supervisory function commanding the computer to retrieve a line of keyboard input from its buffer memory so that the operator is unable to interfere with the manner in which the program is operating the hardware. Pursuant to a subroutine of VDLINE called DISERR, see FIG. 10, the retrieved keyboard characters are returned, the screen is set, the retrieved characters are validated, the computer supervisor is told to put the retrieved characters into its buffer memory, a delay period is instituted to enable the operator to read the retrieved characters now displayed on the screen, memory iscleared, and finally, the cursor is returned.

Following VDLINE is the subroutine DELAY, see FIG. 11, which simply interjects time delay in the program's program. DELAY is a short subroutine commanding the computer to loop about branch DELO5 until all of the keyboard characters which were retreived by the VDLINE subroutine are exhausted. The program then returns.

The next subroutine of AUTOGRAM is BUFSET, see FIG. 12, BUFSET is a program for clearing a specific portion of buffer memory. A subroutine of BUFSET is CLRMEM, see FIG. 13. CLRMEM is another short routine which clears a portion of buffer memory and returns.

The next two subroutines of AUTOGRAM are CLRDC1 and CLRDC2, see FIG. 14. CLRDC1 and CLRDC2 are identical routines which assist BUFSET in clearing buffer memory. The program proceeds through branch CLRDC9 to clear a specific portion of memory. Each subroutine sets parameters regarding the portion of memory to be cleared and then proceeds to the CLRMEM subroutine to actually perform the clearing functions prior to returning.

Initiate screen, INITSC, see FIG. 15, is the next subroutine of AUTOGRAM and is used to clear the display screen. VDCHAR, see FIG. 16, is the first subroutine of INITSC. VDCHAR includes the supervisory command, RST8; the subroutine DISERR, previously described with reference to FIG. 10; and a RETURN. Following VDCHAR, is the subroutine SETSCR, see FIG. 72, which saves the bottom line of the screen, for error message display. The final subroutine of INITSC is another VDCHAR, previously described with respect to FIG. 16, which sets the cursor to a prescribed location, usually in the 24th line.

Now that the "housekeeping functions" have been set, branch DATA4 is accessed. The first subroutine of DATA4 is GETIFN, see FIG. 17. The first subroutine of GETIFN is INFILN, see FIG. 18. INFILN is a command in which a file name is inputted. The next subroutine of GETIFN is FNDRET, see FIG. 19, which locates the end of the file name and returns. COMFLS follows, see FIG. 20, and it is a subroutine which takes thhe name of the file just located, places it into the control block and adds on necessary extension. COMPL1, see FIG. 21, is a subroutine which takes the length of the file and the remainder of the input and completes the parameter list. The COMPL1 subroutine adds additional parameters to the list until it is completed and then returns. The subroutine following COMPL1 is PRISDM, see FIG. 22, which prints a display message concerning the creation of a data base by using subroutine VIDKEY, see FIG. 139. The program then actually opens the data base with OPEN, see FIG. 47. If a file is opened for the first time, the program returns to AUTOGRAM. If the file name already exists, the program branches to GETIN5 which reads the next record with READNX, see FIG. 140. The program loops through READNX to obtain the input file name and to read the next name character-by-character, and continues reading until all the individual characters for a particular display have been read. After all the individual characters in a particular file have been read, the program passes from the loop to a close command CLOSE, and finally, transfers the file to the screen with RAMVID before returning to AUTOGRAM.

The next subroutine of AUTOGRAM, still referring to FIG. 1, is GETOFN, see FIG. 23, which is a subroutine similar to GETIFN in that a file name is retrieved and checked for validity. Should the name be invalid, the computer requests that it be restated. The name could be invalid if it exceeds a predetermined number of characters, if it uses reserved characters, or if it starts with a number. Once the name has been validated, the FNDRET subroutine, See FIG. 18, is accessed for locating the end of the line. Finally, COMFLS, see FIG. 20, is used to complete the file specifications.

This subroutine basically allows the computer to type in certain characters for the operator.

The next major branch of AUTOGRAM is called DATA5 which begins with subroutine KBINIT, see FIG. 24. KBINIT is a function of the supervisory hardware which resets the buffer memory to zero so the operator is free is start from scratch. Following KBINIT is the subroutine CLR24, see FIG. 25, which is similar to other clearing subroutines because it sets the scroll is protect the bottom line and calls on the VDCHAR subroutine, previously described with reference to FIG. 16, to place the cursor in the correct location. Because it is undesirable to remove newly displayed input from the screen, the entire screen is cleared only if the cursor is located in the topline, otherwise if the cursor is in the bottom portion of the screen, only the bottom line is cleared. VDGRAF, see FIG. 26, is a subroutine which outputs special characters through a supervisory call. For example, the cursor is returned to its home position at the upper left-hand corner of the screen. The final subroutine of branch DATA5 is CLRDL1, see FIG. 27, which clears a block of memory.

The program then moves to the EDITOR branch of AUTOGRAM which begins with the SAVCUR subroutine, see FIG. 28, wherein the program identifies the location of the cursor by checking the hardware registers and presenting the numbers which identify that location. The subroutine under SAVCUR is VDREAD, see FIG. 29, which is another supervisory call for reading a section of input. The next subroutine of EDITOR is CLRPRT, see FIG. 30, which first calls CLR24, previously described with reference to FIG. 25, to clear the 24th line, and second prints out a message through the PERMSG subroutine, described later with reference to FIG. 70 (usually an error message, although it could be instructional). Now the location of the cursor is known and the cursor has printed a message. The final subroutine of EDITOR is RESCUR, see FIG. 31, which returns the cursor to its original position by issuing a supervisory call through VDGRAF, previously described with reference to FIG. 26, and returning the cursor to the next location.

The next AUTOGRAM branch is labeled EDIT02. The first subroutine thereunder is GCURSR, see FIG. 32. GCURSR simply tells the supervisor hardware to cite the location of the cursor. If for some reason the supervisor is unable to locate the cursor, it returns with an error message; VDREAD, previously described with reference to FIG. 29, is employed to command the supervisory hardware to move on to the next location and then return. Since it is possible for the cursor to move into the system line and off the edge of the screen, VDGRAF is used to move the cursor to a desired location or to keep it within a particular area on the screen. Then the cursor position is read and if its within acceptable boundaries, it is returned. If however the cursor is not located within acceptable boundaries, it is repositioned and then returned.

The next subroutine under EDIT02 is KBCHAR, see FIG. 33, which is a request to the supervisory hardware to retrieve a previously inputted character by going to the character memory buffer and returning with that character. The loop following KBCHAR is employed for purpose of determining whether a character was retrieved from buffer memory. It is possible that no character was in the buffer memory and therefore nothing was returned. If KBCHAR has retrieved a character, it is placed into the subroutine called LOOKUP, see FIG. 34, which is another supervisory subroutine in which a high speed search through adjacent bytes of memory is conducted to determine whether another character of the same description can be located. The subroutine returns from the search, with or without the character, and provides specific information about where the character was or was not located. Whether or not the character is located, AUTOGRAM branches to EDITR5. The GCURSR subroutine, previously described with respect to FIG. 32, moves the cursor to the desired position, takes the character that was not located in the LOOKUP table and displays that character on the screen before returning to branch EDIT02 to locate the next character. VDGRAF, previously described with respect to FIG. 26, is the output subroutine for displaying the character.

If the character is located, the EDIT02 routine shifts to the SAVCUR subroutine, previously described with respect to FIG. 28, which locates the cursor, places that location in buffer memory, clears out line 24 through the CLR24 subroutine, previously described with respect to FIG. 25, and restores the cursor through the RESCUR subroutine, previously described with respect to FIG. 31. The program then continues with H and L.

FIG. 2 indicates the possible points at which the program can continue in the editing mode. If, for instance, the program continued at EDLFTA, see FIG. 2A, the input would be placed in a register and then shifted down to EDGRC, see FIG. 2B, which is an editor graphics control branch. That branch basically outputs the character by retrieving the cursor through GCURSR, previously described with respect to FIG. 32, and restores the cursor to its original value at the beginning of the EDITOR branch through VDGRAF, previously described with respect to FIG. 26, so that it is in position to retrieve the next character.

The EDUPA subroutine, see FIG. 2C, provides several alternatives. Before proceeding with an explanation note that the EDLFTA and EDGTA subroutines, see FIGS. 2A and 2W respectively, are designed to display a character on the screen and return to the EDITOR branch. The EDF1 subroutine, see FIG. 2D, accesses the PRTEHS subroutine and then returns to the EDITOR branch. The EDF2 subroutine, see FIG. 2E, does a SCNPRT, described below with respect to FIG. 46, and returns to the EDITOR branch. From the foregoing, it is obvious that there are many ways of returning to the EDITOR branch.

Depending on the cursor's position, the "up arrow," EDUPA subroutine of FIG. 2C outputs the character in either of the following manners: (1) to the screen through the subroutines GCURSR, previously described with reference to FIG. 32, and VDGRAF, previously described with reference to FIG. 26, and returns to the EDITOR; or (2) outputs through VDGRAF to the EDITOR branch. Again, the choice depends on the positioning of the cursor. If the cursor is at the bottom line of the screen, for example, the subroutine moves to EDUPA5, see FIG. 2F, at which point the cursor is transferred to the first line. If the cursor was at the 23rd line and it was necessary to relocate the position up on line, VDGRAF would allow the cursor to move up one line. However, if the cursor was positioned in the first line and it was desired to move the cursor up one line, a check of the cursor's position would result in the computer stating that further upward motion can only be accomplished by rolling around the bottom line to the line one above it (line 23), because the bottom line is reserved for message space. In other words, the determination of cursor movement is made for the operator. That is the function of the EDUPA5 subroutine. It wraps around the bottom line so that the line is reserved for message space.

The special processing of nearly every character by the editor mode of FIG. 2 results in a return to the EDITOR branch. The "down arrow" EDDWNA subroutine, see FIG. 2G, does essentially the same thing as EDUPA, including a check of limitations. The down arrow employs subroutines GCURSR, previously described with respect to FIG. 32, and VDGRAF, previously described with respect to FIG. 26, to backspace and move the cursor to a special location depending upon the line at which it is presently located.

EDCTLQ, and GRCTLQ, see FIG. 2H, both return to the EDITOR branch of FIG. 1. EDF1, see FIG. 2D, is a program which prints and displays the editor help screen through subroutine PRTEHS, see FIG. 35, which is a message informing the operator exactly what can and cannot be done. PRTEHS includes the VIDRAM subroutine, see FIG. 36, which first transfers the video display to a special memory buffer in the RAM through a supervisory call; and second, returns to the EDHSA branch of the subroutine to select a keyboard key. If the F1 key is inputted, the PRTEHS subroutine follows branch EDHSB which re-displays the RAM just removed from the video screen and returns to the EDITOR branch. RAMVID, see FIG. 36, is a subroutine identical to the previously described VIDRAM subroutine. RAMVID uses a very large RAM which initiates a supervisory call to transfer the screen display to accessible memory because there is no access to the memory from the screen display itself. The subroutines RAMVID and VIDRAM of FIG. 36 are actually not subroutines because they actually determine the transfer to memory and accomplish the transfer when the F2 key is depressed. If the F2 key is inputted, the SCNPRT subroutine, see FIG. 46, of EDHSA is accessed to display the editor help screen. SCNPRT is a subroutine comprising of a single supervisory call, namely, a return command, RETCMD. The RETCMD, see FIG. 104, command tells the supervisor to dump everything that is on the screen to the printer.

The EDCTLR subroutine, see FIG. 21, of the EDITOR branch is a loop which is essentially a self-contained module. It scans the descision point through VDCHAR, previously described with respect to FIG. 16, to see if it's already in reverse video. If it is not, it outputs a character and returns to the EDITOR branch. If it is in reverse video, it outputs a character so that the next time EDCTLR is accessed, it is moved out of reverse video. This is a continuing process so that the first time the control is typed in, it is placed in reverse video and the next time, it is taken out of reverse video. If it is in reverse video, it proceeds to branch EDRO5, see FIG. 2J, through VDCHAR, previously described with reference to FIG. 16, and then returns to the EDITOR branch.

The subroutine EDCTLD, see FIG. 2K, and a subroutine contained therein, DELCHR, see FIG. 37, are basically word processing functions which permit the insertion of characters while maintaining the remainder of the display on the screen. When a character is to be inserted, its position is noted, all the characters after that position are moved over one position and a new character is inserted in the open position. Likewise, when a character is deleted, the remaining characters move into the vacated position. More particularly, and viewing FIG. 37, the deletion of a character is accomplished by the following operations: (1) obtaining the current cursor position through subroutine GCURSR, previously described with respect to FIG. 32; (2) performing a VDREAD subroutine, previously described with respect to FIG. 29, which reads the line rather than just the character; (3) moving through a rather small branch called DELCH5 to determine the position of the character on that line; (4) deleting the character; (5) moving over the remaining characters; (6) returning the cursor to the beginning of the line; and (7) reprinting everything onto the screen in such a quick manner that it is impossible to determine the individual performance of the operations.

The foregoing deletion of a character is accomplished through a subroutine of branch DELCH5 called SDGRAF, see FIG. 38. The SDGRAF subroutine is initiated by VDCHAR, previously described with respect to FIG. 16, which determines the position of the cursor at the beginning or the end of a line. If the cursor is occupying a valid position, the subroutine SNGRAF, see FIG. 73, uses the subroutine VDGRAF previously described with respect to FIG. 26, to return with the cursor position. The program then flows to the SDG03 branch to determine the correct cursor location and loop through this branch several times depending upon the number of characters inputted. When all the characters have been validated and located on a particular line, those characters are printed and displayed through the previously described subroutines VDCHAR, SNGRAF and VDCHAR. The subroutine ends by returning the cursor to its correct position. In other words, the subroutine first loops through branch SDG03 to move the characters over. After completing the character relocation, the subroutine goes to branch SDG05 and replaces characters in the vacated positions. Finally, it determines that it has completed the process and replaces the cursor.

Another editor control subroutine is EDCTLH, see FIG. 2L, which takes single characters and commands VDGRAF, previously described with respect to FIG. 26, to display those characters on the screen. Again, it is a hardware function causing the cursor to move to the upper left-hand corner of the display screen.

Another FIG. 2 (editor mode) subroutine is EDCTLI, see FIG. 2M, which includes the single subroutine INSCHR, see FIG. 39. EDCTLI is a subroutine similar to DELCHR, see FIG. 37, in that a character is first referenced, the bottom line of the screen is cleared, and a message is printed on that bottom line informing the operator that the program is now in the character mode. Unlike DELCHR, however, a character is not deleted every time the subroutine is called. With the INSCHR subroutine, any number of characters can be inserted while the cursor remains stationary. Referring to FIG. 39, the cursor is first placed in the desired location through subroutine GCURSR, previously described with respect to FIG. 32, and a message is displayed on the screen. So that the operator is fully informed prior to beginning this routine, the lines are read onto the screen through the CLRPRT subroutine, previously described with respect to FIG. 30, and the program moves to branch INSCH5, through subroutine VDCHAR, previously described with respect to FIG. 16. Branch INSCH5 obtains the character to be inputted and depending upon the length of the line, different branches may be followed. More than likely it will continue to branch INSCHBP wherein the character is inserted before the position. The program then moves to branch INSCH6 which is a simple logic routine flowing into branch INSCH9. The INSCH9 branch includes subroutine SDGRAF, previously described with reference to FIG. 39, wherein the characters are moved over a position. The next subroutine, VDGRAF, previously described with reference to FIG. 26, displays the characters on the screen. At this point, the program may return to branch INSCH4 in which a line is read in its new position. Branch INSCH5 then obtains the next character, and so on. Alternatively, if another control is inputted, the INSCHR subroutine branches to INSCH7 which clears the bottom line of the screen through CLR24, previously described with respect to FIG. 25; moves to the SETSCR subroutine, previously described with reference to FIG. 8, wherein the position of the scroll is set; and, returns the cursor through the VDGRAF subroutine, previously described with respect to FIG. 26. However, if an invalid character is inputted, there is a return to branch INSCH5 which requires the operator to input another character. Should a line be inserted in a blank space, the subroutine branches off to SDGRAF, previously described with respect to FIG. 38. In this instance, it is possible to exit in a quicker way than the reprinting of the entire line. In other words, wherever possible, the program loops arounds unnecessary code to find a quicker route.

The next two subroutines in the editor mode, EDCTLK, see FIG. 2N, and EDCTLL, see FIG. 2P, employ the DELINE and the INLINE subroutines, respectively. INLINE and DELINE subroutine are found in FIG. 40. These subroutines use what is called "a self-modifying code." After entering the subroutine, a common branch INDELN is reached. In INDELN, subroutine VIDRAM, previously described with respect to FIG. 36, inputs the current line on the screen. As previously described, the video display is stored in RAM. The cursor is positioned and saved through the previously described GCURSR subroutine see FIG. 32. It then proceeds into a MLTPLY subroutine, see FIG. 41, which basically goes to memory where the fact that there are 80 characters per line is known and then the particular line being inserted or deleted is inputted. For instance, if line 6 is being deleted, the routine multiplies the 80 characters by 6 lines and this sum is added to the current position of the cursor. Once this position is determined, branch INDEL4 will move the lines up or down, irrespective of whether an insertion or deletion of a line is occurring. It then proceeds to the subroutines under branch INDEL5, namely, CLRMM2 and RAMVID, previously described with reference to FIGS. 6 and 36, respectively. In these subroutines, the last line is cleared and the line is transferred back from RAM to the video. Finally the cursor is returned. If the cursor is on the first line of the screen, a line cannot be inserted. Whereas, if the cursor is on the bottom line of the screen, a line cannot be deleted.

The next editing mode entry is EDCTLM, see FIG. 2R, which uses the subroutine, CENTER, see FIG. 42, to center characters on a line. The first subroutine of CENTER is CLRDL1, previously with respect to FIG. 27, which clears a buffer area DL1 for use as a line buffer. Next, subroutine GCURSR, previously described with reference to FIG. 32, locates the cursor position relative to the line that is being inputted. Subroutine VDREAD, previously described with reference to FIG. 29, reads the entire line into the DL1 buffer and th SEARCH subroutine follows, see FIG. 43. The SEARCH subroutine is performed by beginning at the start of the line, searching for and saving the first non-blank character. The cursor is returned and an UNSEAR subroutine, see FIG. 44, is enacted. To unsearch, the line is searched from the end until the first non-blank character is reached and the cursor is moved laterally by taking the difference between the search character location and the unsearch character location. The VDREAD and SDRGAF subroutines, previously described with reference to FIGS. 29 and 30 respectively, are then used, to set the position of the cursor before moving to branch CNC100. SDGRAF takes the memory buffer and displays the entire line on the screen in its adjusted condition. However, rather than moving the characters, the pointer is centered and the printing is initiated from that position. The line buffer is cleared so that it is ready for the next time it is needed and the SEARCH and UNSEAR subroutines are referenced relative to the direction they are to move. Since SEARCH and UNSEAR are limited to 80 characters apiece, if they do not find the character in a particular line, they display the line as a blank.

The next editor control function is EDCTLS, see FIG. 2S, which is used to save data displayed on the screen, give it a new file name, and finally return to the EDITOR branch. The first subroutine of EDCTLS is SDATAD, see FIG. 45. The first subroutine of SDATAD is COMPL1, previously described with reference to FIG. 21, which completes a parameter list. The next subroutine is CLR24, previously described with reference to FIG. 25, for clearing the bottom line of the screen. The subroutine PRIDSM, previously described with reference to FIG. 22, is used to print a message stating that a data base descriptor has been created. The subroutine OPEN, see FIG. 47, is a supervisory call for opening a new file. Line 24 is then cleared through the subroutine CLR24. VIDRAM, previously described with referenece to FIG. 30, is used to clear line 24 and redisplay the original message. SDATAD then flows to branch SDATA5 to loop through subroutine WRITNX, see FIG. 48, which employs the previously described RST8 and DISERR subroutines to transfer the characters removed from the screen into a disk file. When the last character is transferred to the file, the program moves to branch SDATA6 and the CLOSE subroutine, see FIG. 49, which is another supervisory command to close the file and return for purposes of obtaining a new file name. Finally, the program returns to the EDITOR branch.

The next set of routines discussed are editor control subroutines which, like EDCTLQ previously described with respect to FIG. 2H, branch to portions of the program other than the EDITOR branch. For instance EDCTLG, see FIG. 2T, moves to subroutine GRINP which is located at the bottom of FIG. 3. These are essentially translation factors. For instance, when the character "A" is inputted, it is really desired to have that character "A" displayed on the screen. It is accordingly possible to have output characters of a graphics nature and of a character nature.

Editor escape, EDESC, see FIG. 24, includes only the subroutine ENDPR5, which is illustrated in FIG. 50. The first subroutine of ENDPR5 is SETSCR, previously described with reference to FIG. 8. Line 24 is then protected through subroutine SAVL24, see FIG. 51, save the characters on line 24. The line is cleared and printed using CLRPRT, previously described with reference to FIG. 30. The subroutine INCHAR, see FIG. 52, then prints out a message for which a yes or no response is necessary. If the response is yes, the ENDPR5 subroutine continues of branches ENDPR2 and END999 so as to close all files through subroutine CLOSE, previously described with reference to FIG. 49. The break key is then reset through VDCHAR, previously described with reference to FIG. 16, and SETBRK, previously described with reference to FIG. 8. However, if the response is no, the CLR24 subroutine, previously described with reference to FIG. 25, is initiated to clear line 24 and a RESL24 subroutine, see FIG. 53, is used to restore line 24 to its pre-existing condition.

The final non-EDITOR-returning subroutine of the editor mode is EDCTLE, see FIGS. 2 and 4. EDCTLE proceeds to subroutine FLDCHK, which instructs the computer to end the editing mode and begin the automatic program generating mode.

Now that the subroutines of the editing mode of FIG. 2 has been described in detail, the parallel subroutines of the graphics mode of FIG. 3 may be expeditiously described in the following manner. Access to the graphics when in the editing mode of FIG. 2, inputting EDCTLG, see FIG. 2T, puts the editor into the graphics mode of FIG. 3. Pressing the F1 key then displays the graphics help screen in which the upper case letters (A to Z) and numbers (1 to 6) print various graphical characters, Pressing the F1 key a second time returns to the working screen on which the graphical characters may be entered to create the appearance of a printed form.

More particularily, each of the followinng routines represent a graphical character which can be printed onto the screen: GRCONA, see FIG. 3A; GRCONB, see FIG. 3B; GRCONC, see FIG. 3C; GRCONP, see FIG. 3D; GRCONQ, see FIG. 3E; GRCONR, see FIG. 3F; GRCONS, see FIG. 3G; GRCON1, see FIG. 3H; GRCON2, see FIG. 3I; GRCON3; see FIG. 3J; GRCON4, see FIG. 3K; GRCON5, see FIG. 3L; and GRCON6, see FIG. 3M.

The following chart relates the parallel graphics mode and editing mode subroutines. Since these subroutines are identical to the editing mode subroutines previously described, except for the different mode, further description is believed t be unnecessary relative to the graphics mode.

Referring now to FIG. 4, the FLDCHK subroutine flow chart is illustrated. The FLDCHK subroutine includes the VDCHAR subroutine, previously described with reference to FIG. 16, and the CLRPRT subroutine, previously described with reference to FIG. 30, which sets the cursor at the 24th line and prints out a message indicating that a check of the fields is occurring. As FLDCHK checks the fields, a subroutine FNDFLD, see FIG. 54, is called. FNDFLD scans the screen to determine the existence of fields. Upon entering the next field position, it reads a character from the screen through the VDREAD subroutine, previously described with reference to FIG. 29, and attempts to determine if that character is: (1) the beginning of a field; or (2) an error. If the whole field is a single character, it is quickly processed and the program returns through branch FND07. At this point the program is being created, but the validations have as yet to be reached, so the field characters are unimportant. If the beginning or start of a field is found, flags are reset to indicate and save that fact for later reference. The computer then moves to branch FNB02. Note that the words, "start" and "finish" are used to indicate prompted fields, while the words "beginning" and "end" are used to indicate non-prompted fields. Since beginnings and endings can be mixed, branch FNB04 is entered where a whole character or an alpha-numeric character may be found to be in error. At this point, the invalid character follows an erro subroutine, FNDERR, in which the appropriate error message is displayed on the screen and then returns to the EDITOR branch. If no error is found, successive characters are continuously processed until the finish or end of a field is located. When the finish or end of a field is located, the computer either goes to return or into branch FNDEN9 and then RETURN. The decision point depends on whether it is the end of a field or the finish of a field; i.e., the computer will add one to the length of a non-prompted field or remain stationary if the field is a prompted field. In either case, the return is to the flag set from which it flows either by specification or defalut into branch FNB02 and returns. If, on the other hand, it is desired to end the computed field, the correct value is set and a return occurs. If the end has not yet been reached, an error message is displayed. After the error message is printed, see ERR5 through ERR12, the individual error causing the initiation of the FNDERR subroutine is displayed on the screen. This is accomplished by feeding the response of the tripped error indicator into branches FND99, FND100 and FND101. The VDGRAF subroutine, previously described with reference to FIG. 26, sets the cursor position at line 24 and prints the error message. After receiving a keyboard stroke input, the cursor is automatically positioned at the point of error. The computer is essentially indicating the operator not only made an error, but informing the operator of where the error is located, and then awaiting the entrance of a keyboard character, see subroutine KBCHAR, previously described with respect to FIG. 33. The message also instructs the operator to press the spacebar in order to continue. When the spacebar is depressed, the cursor is placed at the point of the character which caused the problem and a return to the editor mode enables the problem to be corrected.

At this time, EDCTLE can again be inputted to reinitiate the process. If the keyboard character has not been inputted at this point, the computer will remain in the type loop. The FND101 subroutine is therefore simply a loop to insure that a character is inputted.

Note that while FNDFLD is the main subroutine of FIG. 54, the program may also enter FNDFLD under the FNDERR subroutine. Therefore, the FNDFLD subroutine is essentially a mini-interpreter to which a single character is forwarded and converted into a meaningful message which requires operator response. Also, encoded in the response from the FNDFLD subroutine is a description of the form of error message after which the program returns to the EDITOR branch or flows to branch FLD99, indicating that everything is proper. Alternatively, the EDCTLE subroutine of FIG. 4 may continue at branch RLTL. The RLTL branch indicates the record is too long, a function not available in the FNDFLD subroutine. The computer will therefore return, display the message that the record is too long and proceed to branch FND99, see FIG. 54. The program either returns to the EDITOR branch or flows to branches FLD06, FLD07, and FCTM prior to returning to the EDITOR branch. The FCTM branch indicates that the field count is too great.

It should be apparent that the errors handled by the FCTM branch are ones which the FNDERR subroutine is unable to handle. These represent errors which infrequently occur because the number of fields and the length of the records is almost unlimited. It was therefore deemed to be more efficient to handle each separately. Accordingly, FCTM is the general purpose error handling branch, while FNDERR is a very specific error handling subroutine. Therefore, after determining the number of fields and the length of records to be proper, the computer proceeds to branch FLD99 where subroutine CLRPRT, previously described with respect FIG. 30, clears the bottom line and prints the message. Then a data base descriptor file is created through subroutine SDATAD, previously described with respect to FIG. 45. The message remains for the period of time that a delay is set as previously described with respect to FIG. 11. Finally, the data on the display screen is saved by typing EDCTRS.

The display screen that has been saved is forwarded to INFVAL, which is a field validation branch found in FIG. 4. The first subroutine under INFVAL is FLDVAL, see FIG. 55, FLDVAL is that part of the routine in which the computer is informed of the meaning of the field values and exactly what can be or cannot be typed into those fields. More particularly, FLDVAL permits the inputting of validations by first clearing memory pursuant to the CLRMEM subroutine, previously described with reference to FIG. 13. There are a couple of specific locations in memory to be cleared out, herein referred to as FLD5 and the location memory. Then the FNDFLC subroutine, see FIG. 56, is called for obtaining those field specifications created when the screen was examined. When the specifications are returned, the computer asks the questions: (1) whether that was the last field; and (2) whether a field was returned. If a field was returned, it continues straight down and reverses the video display of the field on the screen to highlight it. The FNDFLC subroutine searches through the field table to locate the field number, a number which is maintained internally. The FLDVA5 branch of FIG. 55, is continuously looped until all the fields in the field table have been completed. For instance, if a search is being conducted for FLD3, FLD1 through 99 are searched until an error message appears either: (1) indicating FLD3 was located; or (2) the program returns with no error message set. When the search returns with the field, all the specifications about the field are displayed, i.e., its location, its length, the field validations, etc. If the field has been located, the field is reversed pursuant to subroutine REVFLD, see FIG. 57. The subroutines under REVFLD are: FNDFLC, previously described with reference to FIG. 56; VDREAD, previously described with reference to FIG. 29; VDCHAR, previously described with reference to FIG. 16; VDGRAF, previously described with reference to FIG. 26; VDCHAR, previously described with reference to FIG. 16; and RETURN. It then returns to branch FLDVA5 and moves to the INPVAL subroutine, see FIG. 58.

The INPVAL subroutine sets input validations. INPVAL first passes to branch GETVAL which essentially decides whether a maximum number of validations have already been set. If a maximum has not been set, a message is displayed which states "input validation," the cursor is moved into the correct position and the current validation list is displayed. The foregoing is accomplished through the subroutines: DISMSG, see FIG. 59, to display the message; CURSON, see FIG. 60, to move the cursor; PRVLST, see FIG. 61, to print the validation list; VDGRAF, previously described with reference to FIG. 26, to attain the current cursor position; and finally, GVAL, see FIG. 62, to perform a validation check.

The first subroutine under GVAL is KBCHAR, previously described with reference to FIG. 33, which looks for keyboard input and continues searching until a keyboard character is inserted. KBCHAR is programmed to check for two input characters per validation. Therefore, the first keyboard character places the computer into a loop in which it checks to see if an F1 key was inputted at subroutine VALF1, see FIG. 166. If an F1 character was typed, the validations are displayed on the help screen until another character is inputted. If an F1 character is not typed, but rather, a valid character or an alpha character is typed, the program moves branch GVAL3 and through VDCHAR, previously described with respect to FIG. 16, prints the inputted character onto the screen and moves to branch GVAL4. In the GVAL4 branch, the second of the two keyboard characters is located. The program then loops thereabout until a character is inputted and displayed on the screen. At this point, the loop between the F1 key and the help screen becomes activated. For instance, to preclude the possibility of typing in the first character and the forgetting that that character was inputted, the F1 key will display the help screen. If another valid character is typed, the program goes to branch GVAL5, where that valid character is printed through a VDCHAR subroutine, previously described with reference to FIG. 16, prior to returning to INPVAL.

If the return was by a carriage return, branch GETVA3 of INPVAL is accessed. The GETVA3 branch first goes to subroutine CHKVAL, see FIG. 63, the purpose of which is, in general terms, to obtain validation of the two characters which were inputted. If the validation is proper, the validation is displayed on the screen and the program proceeds to process another validation. If on the other hand, the validation is improper, an error message is printed through the subroutine PRTMSG, see FIG. 64, the error message is displayed through the DELAY subroutine, previously described with reference to FIG. 11, and finally, the error message is erased and the computer returns for the next validation check of that character. The subroutine has two exits; (1) the MAXVAL branch which includes the PRTMSG subroutine, previously described with reference to FIG. 64; or (2) or the input of return.

From either the MAXVAL or the GETVA3 branches of INPVAL, the program enters TRNVAL. The TRNVAL subroutine transfers two input characters to the memory buffer that was previously cleared for the purpose of creating a string of characters for the program to decipher at a later time. The field which was reversed is now corrected and the cursor is replaced on the loop to locate another field. If another field is located, the loop is followed around once again. Finally, when all of the fields are complete, the computer moves to the COMVAL branch which stands for complete validation, see the subroutines FNDVAL and FLDVAL in FIGS. 185 and 65 respectively. The COMVAL branch performs various logic functions to determine whether the particular validation requires completion. If completion is necessary, the program performs the following operations: (1) follows the side loop to locate the field and obtain its specifications; (2) reverses the field; (3) locates the field validations previously entered; and (4) displays the field validations pursuant to the subroutine DISPVL, see FIG. 65. Subroutine DISPVL prints a message onto the screen and returns to branch COMVAL. This process is repeated until a field requiring an interpretive validation is located. It essentially looks at the type of validations inputted for all the fields and when one which requires additional information is located (such as a default value) it branches off into the INTERP branch, see subroutine FLDVAL in FIG. 55. The program moves from branch INTERP into the FNDFLC subroutine, previously described with respect to FIG. 56, to locate the proper field specifications, and if necessary, calls the computed field interpretive subroutine CFINTP, see FIG. 167, or the default value interpretive subroutine, DVINTP, see FIG. 168. Generally, the CFINTP subroutine will interpret the program's next function by calling subroutines INSTKN, INTPOA, INTPFA, INTPOP, CHKIAV, and INSEOV, respectively set forth in FIGS. 169, 170, 171, 172, 173, and 174. Subroutine DVINTP additionally calls subroutine KBLINE, see FIG. 141, to perform similar interpretive functions for a default value. This process is sequentially repeated for all of the fields; first for the normal validations, and then for the interpretive validations. In other words, it completes all of the normal validations prior to proceeding with the interpretive ones.

After returning from FLDVAL, the next subroutine is CRTDBS, see FIG. 66, which creates a data base. This is accomplished by calling the subroutines of CLRPRT, FNDRET, COMPL2, OPEN, and CLOSE, previously described with reference to FIGS. 30, 21, 47 and 49, respectively. CRTDBS will clear the bottom line through the subroutine CLR24, previously described with reference to FIG. 24, locate the end of the name that was originally inputted, complete the parameter lists, open the data base file and close the data base file.

The next subroutine CRTKYF, see FIG. 67, follows essentially the same subroutine for the key file, as was followed by the data base creation subroutine, CRTDBS, described in the precedinng paragraph. The lone exception is that it must additionally clear some memory. There is actually not much difference between the CRTDBS and CRTKYF subroutines except for the names which are employed.

The computer then proceeds to the ENDAUT branch which first accesses the BINHEX subroutine, see FIG. 68. BINHEX is a program for converting numbers from binary to hexidecimal. During ENDAUT, the size of the application program is calculated based upon the validations and upon the known length of the subroutines. The result is a binary number for the beginning and a binary number for the end of the fields. The difference between the two values is converted from a binary to a hexadecimal value which the operating system can understand. MOVDP3, see FIG. 69, is the next subroutine in ENDAUT. MOVDP3 is a subroutine for placing those binary and hexidecimal numbers into a preset string which tells the operating system to save the program. Subroutine MOVDP3 is necessary to store the beginning and to store the end of the field.

The computer then moves to the ENDAU9 branch which essentially determines the point at which AUTOGRAM begins and ends through the BINHEX program, previously described with respect to FIG. 68, and a MAPD1 subroutine, see FIG. 138. It then takes the old memory, changes the old memory to zero through a FNDEDP subroutine, see FIG. 71, and issues a return command.

Finally, the computer jumpst to ENDCRE, which is the end of the creation phase. It sinply states the program is complete and returns the operator system so that, for security, no trace of the program remains.

Referring now to FIG. 74, the generated or automatic application routine, labelled INITAP, will be described in detail. INITAP begins with subroutine VDCHAR, previously described with reference to FIG. 16, which clears the display screen. The next subroutine of INITAP is set scroll SETSCR, previously described with reference to FIG. 72, which protects the bottom line so that a sign-on message can be printed on the display screen. With this program, a typical message includes a copyright notice and a security check of the program's serial number.

The next subroutine is PRTSGN, see FIG. 75, places the screen cursor into position and prints out the serial number of the program by calling the VDCHAR subroutine, previously described with reference to FIG. 16. The PRTSGN subroutine recalls the serial number through a series of subroutines scattered throughout the program. VDCHAR retrieves the characters of the serial number from their various positions inside the program and then returns to the initial position. Displaying the serial number acts as a security device to alert the user to whether the program has been tampered with. If the serial number cannot be properly recalled by PRTSGN, the program stops. Foiling this security device requires tracing each subroutine containing a character of the serial number. Scattering the subroutines makes tracing through the code difficult. Indirect branches between the serial number subroutines makes it even more difficult to trace the subroutine's path through the code.

Referring back to FIG. 74, the next two subroutines in INITAP are CLRDC1 and CLRDC2, both described previously with reference to FIG. 14, which clear areas of memory that act as device control blocks. Subroutines FLDCB1 and FLDCB2, see FIG. 76, clear areas of memory that act as file control blocks. Following FLDCB2, subroutine FNDRET, described earlier with reference to FIG. 19, finds the name of the program. Then subroutine COMFLS and both subroutines COMPL1 and COMPL2, described earlier in FIGS. 20 and 21 respectively, recall the name of the program and take the length of files 1 and 2, the remainder of the input, and complete the parameter lists. The title is transferred to the top of the display screen by the next subroutine, TRNTTL, see FIG. 77. TRNTTL consists of a supervisor command to perform this function and then returns to INITAP.

The next subroutine of INITAP is deletes non-prompts DELNPT, see FIG. 78. DELNPT searches through the screen memory to identify prompt amd non-prompt characters. When the program is initiated, both prompt and non-prompt characters contained within the program are displayed. This subroutine eliminates the non-prompt characters so that they do not appear on the screen when the program is entered. DELNP3 accomplishes the search through the fields which appear on the screen, identifying the non-prompt characters. The program is presently adapted to indicate non-prompt characters by braces. DELNP7 removes the non-prompt characters from the screen and references the locations the non-prompt characters appeared. When the end of the screen is identified, the program returns to INITAP.

Set key length, SETKYL, see FIG. 79, is the next subroutine of INITAP. The key length is set by calling subroutine FNDFLC, previously described with reference to FIG. 56, which identifies the field specifications for the first field and sets the key length equal to the length of the first field.

The next two subroutines following SETKYL have been described earlier with reference to FIG. 7 as BRKSET and to FIG. 47 as OPEN. These subroutines open a data base and a key file.

The program keeps track of the total number of records in the data base by the next subroutine, DIRRD2, set forth in FIG. 80. This subroutine contains a supevisor command which reads the record and then returns to INITAP. The next subroutine of INITAP is LOCATE, set forth in FIG. 81, which contains a supervisor command and may access subroutine DISERR, previously described with reference to FIG. 10. Subroutine LOCATE locates the number of the record in the data base read by the previous subroutines and uses that number to keep track of the number of records in the data base. Following LOCATE are three subroutines which prepare the display screen for the printing of a menu. CLRMM2 is a subroutine, previously described with reference to FIG. 6, which clears memory to spaces. DELAY and VDCHAR are subroutines, described earlier with reference to FIGS. 11 and 16 respectively, which clear the screen for the eventual printing of the menu.

The program continues through branch DSMENU of the INITAP routine to call subroutine PRMENU. The subroutines accessed by PRMENU are set forth in FIG. 82. After the screen is cleared, the title which is recalled from memory and put on the screen by VDCHAR, described earlier with reference to FIG. 16. A second VDLINE prints out the whole menu. The title is printed out on the first line of the display screen by PRTTIT, see FIG. 83, which calls on a first VDLINE subroutine to accomplish the printing.

The next branch of INITAP is DSMEN2 which recalls a character from the keyboard and will continue to loop until the character is inputted. Depending on the menu selection, five major subroutines can then be selected. The subroutine INCHAR, previously described in FIG. 52, performs the looping function.

The first major subroutine on the menu, ADDREC, is set forth in FIG. 84 and is used to add a record to a data base. The program flow through ADDREC will either branch to ADREC3 or ADREC4 depending on whether the generated program contains a data base. Subroutine SETTIT, see to FIG. 85, transfers the title to the top of the display screen.

The program continues into branch ADREC5 and subroutine ARAMVD, see FIG. 86, which takes a particular location in memory and transfers it to the screen through a supervisor command. In this case, the particular location is where the program stored the screen.

The next subroutine in branch ADREC5 is INLOOP which is set forth in FIG. 87. The program flows through branch INLOP5 of the INLOOP subroutine and recalls the field specifications by using subroutine FNDFLC, described earlier with respect to FIG. 56. Should FNDFLC recall an error message, the program will return to ADDREC and by means of branch ADREC6, and the program will eventually branch to DSMENU of the INITAP routine, see again FIGS. 84 and 74. Generally, the INLOOP subroutine retrieves all of the fields present on the screen. This is accomplished by looping through the subroutine GETINP as many times as there are fields. After all of the fields have been retrieved, the program returns to ADDREC in FIG. 84.

The validation of any inputted field in the INLOOP subroutine is checked by the subroutine GETINP, see FIG. 88. GETINP consists of a pre-validation check of the input performed by subroutine PREVAL, see FIG. 89, which sets a flag accordingly. The subroutine PREVAL and the attendant mathematic subroutines are described in more detail in subsequent paragraphs. If the input is a preemptive validation such as a verified field or a computed field, the program branches to GETIN5. Moving through the GETIN5 branch, the program sets the cursor position using the VDGRAF subroutine, as previously described with reference to FIG. 26. Then subroutine INCHAR, previously described with reference to FIG. 52, retrieves a character.

The value of the retrieved character is tested by branching to GETNA5 where a decision point is reached. If the character value is not that of a special character, the program continues through the branch and calls subroutine VDCHAR, see the description with reference to FIG. 16. If the field input is finished, such as with a verified field, the program will branch to GETIN9 and the next decision point described below. If the character value is part of a computed field, additional input will be needed, so the program branches back to GETIN5 where the cursor is advanced to the next position in order to retrieve another character. The exception to this standard loop occurs when a special character is retrieved from the keyboard. If the special character is a return command, the program branches from GETNA5 to GETIN6 where subroutine VALFLD, see FIG. 90, validates the field. The field is then tested at branch GETFDA in more detail below to check whether the field is valid or invalid. The program then returns to INLOOP if the field is valid, meaning that valid data has been inputted. Otherwise the program branches through subroutine FNDFLC, described earlier with reference to FIG. 56, back to the beginning of GETINP to start at the beginning of the field in order to access the field specifications. The program again proceeds through the loop along this described route. Returning to the decision point in branch GETNA5, should the character value be a special character like the backspace, the program will branch to GETIN7. If the program is at the beginning of a field, the program prevents backing out of the field by flowing through subroutine VDCHAR, which has been previously described with reference to FIG. 16, to prevent the backspace. Then the program continues through the same loop branching to GETIN5. On the other hand, if we are not at the beginning of a field, the program simply backspaces and branches through GETIN8 to access branch GETIN5. Referring back to the decision point in branch GETNA5, processing the VDCHAR subroutine may reach the maximum point of the field. In other words, the last possible character position is accessed. The program will then branch through GETIN9 to perform a field validation as described with reference to FIG. 55. If the field is valid, the program returns directly to INLOOP. If the field is not valid, an error message is printed after a short delay called by subroutine DELAY, as previously described with reference to FIG. 11, and an error message is printed on line 24 of the display screen. Subroutine CLR24 then clears the line as described with reference to FIG. 25. After the line is cleared, the program returns to branch GETFDA and starts the loop at the beginning of GETINP.

Returning to the start of the GETINP subroutine in FIG. 88, the program will continue to check if there are additional fields. If there are more fields, the program branches back to INLOP5. On the other hand, if a special character is responsible for returning the program from the GETINP subroutine, the program reaches a decision point after returning from GETINP. If the special character was an up arrow, the program continues through branch INUPA and backs up one field by subtracting one from the current field number. Then the program returns to branch INLOP5 to start the INLOOP subroutine again. If the special character is a down arrow, branch INDNA is used and the program flows through subroutine LASTFN, set forth in FIG. 91. LASTFN iterates through subroutine FNDFLC, see again the description of FIG. 56, until the last character is found in the field. At that point, an error message indicates that there is no additional field to access and the program branches back to INLOP5. If the special character is a left arrow, the program moves to branch INLA. The left arrow special character poses a problem. If the command were executed and the key field bypassed, any values in the key field would be reduced to blanks. As a result, the records could not be located. Therefore, one must keep track of whether there is another left field. As the program proceeds through branch INLA, branch INLA5 tests whether or not the current field is the first field. If the special character left arrow is inputted and the program is in the first field, the program will loop back to branch INLOP5 in order to receive that field over again. If the current field is not the first field, the program continues through branch INLB5 to test whether it is the last field. Again, the program will loop back to branch INLOP5 to receive that field. If the current field is neither the first nor last field, the program proceeds through branch INLAB and subroutine FNDFLC, previously described with reference to FIG. 56, which allows the program to retrieve the next field number before branching back to INLOP5.

Referring now to FIG. 90 for a detailed description of subroutine VALFLD, note that this subroutine is also called FLDVAL. First, VALFLD conditionally calls subroutine PVALDV, see FIG. 92, which processes the validation of a default value. Whether the PVALDV subroutine is called depends on whether the operator originally selected a default value at the beginning of the program and the particular field now being processed actually has the default value designation. Upon entering the PVALDV subroutine, a test first determines if the subroutine was inadvertently called so that the program can immediately return to the VALFLD subroutine. Otherwise, subroutine FNDFLC, previously described with respect to FIG. 54, finds the field specifications. Then subroutine LOCINT, see FIG. 93, locates the interpretive validation by first proceeding to branch LOCIN3 to determine whether an interpretive validation is present. If the operator did not supply parameters for the default value at the beginning of the program, or if an error resulted within the computer itself, an interpretive validation may not be found and the program loops back to branch LOCIN3 to proceed to the next field. The program will proceed through a table of interpretive values and if it fails to find the requested default value, no information will be displayed on the screen. Essentially you have a blank default value. On the other hand, if the data is located and the program returns with the parameters, branch LOCIN4 is accessed and the program returns to subroutine PVALDV. Returning to FIG. 92, subroutine VDGRAF is next accessed to place the default value on the screen. The program returns to subroutine VALFLD and proceeds to branch FLVLO5. In this branch, there is another provisionally executed subroutine, PVALPW, see FIG. 181. In the present version of AUTOGRAMMER this subroutine is unimplemented and now exists as a simple return. The program proceeds to branch FLVLO7 where the particular field being processed is checked to see if a valid numeric has been indicated. The program always accesses subroutine PVALVN, see FIG. 94. The particular field is retrieved from the display screen through subroutine GETFLD, see FIG. 95. The next subroutine MOVRGT, see FIG. 96, moves the retrieved field to the right by executing branch MOVRO3 a sufficient number of times so all of the characters of the field are moved to the right or the program runs into the limits of the buffer that it has been assigned to. In either case, all characters are moved to the right. When the program returns to subroutine PVALVN, in FIG. 94, branch PVLVN2 tests whether a valid numeric is present by scanning for the left most byte. Branch PVLVN2 reiterates until the left most byte is identified. Then the program continues to branch PVLVN4 where the field presently being processed is compared to a numeric character table by using a supervisor call. If an error is found in this comparison, the program branches to PVLVNE the error routine described in more detail below. At branch PVLVN6, the program identifies plus or minus signs. If more than one sign is identified, the program continues through branch PVLVN7 to identify decimal points. In a valid numeric there is only one decimal point. If other than one decimal point is identified, the program branches to the error routine PVLVNE. The error routine begins by setting the scroll with subroutine SETSCR, previously described with respect to FIG. 72. Then an error message stating that there is an invalid numeric is displayed through the courtesy of subroutine PERMSG, previously described with respect to FIG. 70. After the message has remained on the display screen for a short time through the courtesy of subroutine DELAY, line 24 is cleared with subroutine CLR24. An error flag is set to indicate that the field has not been properly entered. Branch PVLVNE places the cursor at the beginning of the field and requests the operator to re-enter data until a valid numeric is inputted. Branch PVLVN8 checks is there is a second decimal point. If only one decimal point is present, the program branches to PVLVNX. The program returns to VALFLD through branch PVLVNX, after clearing the stacks. Returning to FIG. 90, the program then proceeds to branch FLVLO9 to perform subroutine PVALA6, see FIG. 182. First the program checks to find out whether the subroutine has been accessed before and if it has not, then the program proceeds around to branch FLVL12. Subroutine PVALR6 is unimplemented in this version of AUTOGRAMMER. So, the program simply returns and proceeds to branch FLV12. The dollar and cents validations are processed in this branch. If the validation has never been used, the program branches immediately to FLVL14. Otherwise, the program calls upon subroutine PVALD2, see FIG. 97. Subroutine PVALDC, see FIG. 177, enters at nearly the same point in the program and both access subroutine PLALNV, see FIG. 178. The only difference between the two subroutines is one byte of code. If you enter the subroutine through PVALD2, the program changes one byte of code in the routine to allow processing of more than one decimal place. If you enter the program through PVALDC, the subroutine allows processing of only two decimal places. The same code is basically used to do two separate processes. Referring to FIG. 97, the subroutine begins with branch PVLDC1 which uses subroutine GETVLD, previously described with reference to FIG. 95, to retrieve the field on the screen that is being validated. Because the validation is for dollars and cents, the program right justifies the validation by calling subroutine MOVRGT, previously identified with respect to FIG. 96. The program also checks the error flag to make sure that the load value is proper. Otherwise, the program returns. If the load value is proper, the program proceeds to branch PVLDC2 to locate the right most blank, plus one, which identifies where to end the number because digits after the second decimal place are truncated. Branch PVLDC3 scans for the left most non-blank character to identify the length of the number of the most significant digit. If a decimal point is identified during the scan, the program proceeds to branch PVLDC8. If no decimal point is found, the program continues to branch PVLDC4 to insert a decimal point and two zeros by proceeding through branches PVLDC5 and PVLDC6. Each of these branches inserts one decimal point and one zero. Once there are two decimal points, the program continues through branch PVLDC6 and PVLDCX. The PVLDC8 branch determines whether a decimal point exists and the number of zeros after it. The program proceeds back to branch PVLDC6 if the number has one zero and proceeds to branch PVLDC5 is two zeros need to be inserted. If no decimal points are present, branch PVLDC8 will insert one. The program then proceeds to branch PVLDC9 and determines whether to perform the rounding routine. If the number is not to be rounded, the program immediately proceeds to branch PVLDCX. The program proceeds to PVLDCR if the program is to perform the rounding routine or to PVLDCL if the program is not to round off at the last digit. This is determined by testing the last digit. If the last digit is five or greater, the program proceeds to branch PVLDCR where the last digit is increased by one before continuing to PVLDCX. The program falls through to branch PVLDCL if the last digit is less than five. Branch PVLDCL tests for special characters: PLVDCS tests for decimal points; PVLDCM tests for minus signs; PVLDCT tests for positive signs; PVLDCN tests for valid digits less than nine. These branches provide a means for making corrections where the number may be rounding too high, too low, or out of length of the field. Branch PVLDCX corrects and restores the field length counter to its original position with the new and corrected value. Referring back to FIG. 90, the program then proceeds to branch FLVL14 which will immediately branch down to FLVL15 is subroutine PVALD2 has not been previously called. Otherwise, subroutine PVALD2 operates in the same manner just described for subroutine PVALDC except two digits instead of one are processed. The PVALD2 or PVALDC subroutine in FIG. 97 can actually be modified to process infinite number of digits. Branch FLVL15 conditionally calls subroutine PVALLJ, see FIG. 98. This subroutine first tests whether or not the field is full. If it is, and the program proceeds to branch VALLJF and returns to subroutine VALFLD. Otherwise, subroutine LJFLD, see FIG. 99, is called to left justify the field by using subroutine GETFLD to retrieve the field from the display screen and move it to the left with subroutine MOVLFT, see FIG. 100. In a fashion similar to that described for subroutine MOVRGT, subroutine MOVLFT moves the field to the left. Subroutine PVTFLD, see FIG. 101, puts the field back on the display screen and the buffer is cleared by using subroutine CLRMM2, as previously described with reference to FIG. 6. After the program returns to VALFLD, the validation is tested to find out if it is right justified through subroutine PVALRJ, see FIG. 102. At first, PVALRJ checks to see that it is needed. If it was not necessary that it be called, the program continues through branch VALRJ5 and returns to subroutine VALFLD. Otherwise, subroutine RJFLD, see FIG. 103, is accessed. This subroutine proceeds in a manner similar to the description for subroutine LJFLD, previously described with respect to FIG. 99. Returning to subroutine VALFLD, the program conditionally branches to subroutine PVALVF to verify the field if this subroutine has not been used before. Otherwise, the program branches to PVAL16. The first decision point in subroutine PVALVF, see FIG. 179, determines whether PVALVF was inadvertently called and should return to VALFLD. If the subroutine is needed, the program continues to branch PVALV3 to perform a reverse video on the current field in a manner previously defined with respect to REVFLD in FIG. 57. The field on the screen is highlighted in reverse video to make it easily visible to the operator. Then subroutine CLRPRT prints a message on the bottom line which requests that the operator verify the field with an affirmative or negative response. The program then proceeds to branch PVALV5 for subroutine INCHAR, previously described with reference to FIG. 52. If no character is retrieved, meaning that nothing was typed, the program stays in the loop around branch PVALV5. If the operator affirmatively responds the field is verified, the program branches to PVALV7 where line 24 is cleared by subroutine CLR24. The message is removed by subroutine CORFLD, see FIG. 105, which corrects the field by placing the reverse video back to what it was. Branch PVALV8 next sets the error flag to indicate that an error is no longer present and the program returns to subroutine VALFLD. If there was a negative response concerning the verified field, the program then proceeds to branch PVALV9 which calls subroutines CLR24 and CORFLD to perform the functions just described and set the error flag stating that the present validation is a non-verified field before returning to VALFLD. If in response to the computer's inquiry, the operator presses the escape key, the program branches to VALV6 and calls subroutines CLR24 and CORFLD before returning to subroutine PVAFLD. Referring back to FIG. 90, branch PVAL16 is next accessed by the program to verify the correctness of the error flags that were set in the previous subroutine before returning directly to GETINP or through subroutine PVALKF, see FIG. 183, see FIG. 183, which is an inactive subroutine in this version of AUTOGRAMMER. Other PVAL subroutines which are unimplemented are illustrated in FIG. 184.

We now return from VALFLD to the original calling subroutine GETINP to act upon one of three conditions which have been set. If the field has been verified, the program continues proceeding through GETINP. If the field was not verified, the program back up one field. If the escape key has been entered, the program returns back to INITAP to display the menu.

As demonstrated above, one of the advantages of AUTOGRAMMER is its ability to take into account any contingency. It can be termed a "closed end program." By taking into account any error which may result due to incorrect operator input or machine malfunction, AUTOGRAMMER will not hang up in any subroutine, failing to complete its assignment. If an error is identified, the subroutine will return to the previous subroutine to re-evaluate the input. This makes AUTOGRAMMER self-correcting. If a subroutine is inadvertently called, the subroutine will return back to the calling subroutine to continue through the program.

The PREVAL subroutine, see FIG. 89, will now be discussed in detail. The first decision point in this subroutine determines whether or not the program has been properly called. Then it peforms a general check for pre-empted validations. Once a validation has been identified, the program determines whether it is a yes-no or computed field validation. There are other pre-empted validations which are unimplemented in this version of AUTOGRAMMER and in these instances the program immediately returns to the calling subroutine. For a yes-no validation, the program proceeds to the PVALYN branch and first calls subroutine VDGRAF to print out a message on the bottom line of the screen requesting verification from the operator. The program will accept only a yes-no response. Any other character generates an error message and the program immediately returns to the calling subroutine. The character is retrieved by subroutine INCHAR. With a valid character, the program proceeds to branch PVALY3 and calls subroutine VDCHAR to display that character on the screen before returning. The other pre-empted validations are handled by branch PVALCF, see FIG. 176. The first subroutine called in this branch is LOCFLD, see FIG. 107, which locates the field in the field table. This subroutine retrieves whatever value has been placed in the first register and finds that field number in the field table. In the field table, the starting point of the validation table is located. The subroutine processes each character to determine if it is the correct field number. The subroutine immediately returns if it is at the end of the field table. Once the correct field number is identified, the program loops branch CFLOO9 until the whole field is located. Otherwise, the subroutine is again used for the next entry and table. The next subroutine is LOCTKN, see FIG. 108, which locates a tokenized value that is in the computed field in a manner similar to that described for the above subroutine LOCFLD. The difference between the two subroutines lies in locating a token which is in a different table and in a different memory register. The table is made up of interpretive validations indicated by a token, i.e. B1 indicates an absolute character; B2, an invisible field, B3, a computed field, etc. Some of the tokens listed in the table are not implemented in this version of AUTOGRAMMER. This subroutine indicates the calculation to be performed on the computed field. It is an algebraic equation present when the original program was generated which uses variables instead of absolute numbers. The variables are identified through an interpretive mode and a reference table. Substituting variables allows the program to work on any data imaginable, including data which hasn't yet been added. Thus, the program locates the token and determines whether or not the program is working with an absolute field or value, or with a number entered by the operator in a previous field.

For the latter, subroutine TRNFBF, see FIG. 109, is called to find the field table through subroutine FNDFLD, previously described with respect to FIG. 56. Then subroutine PVALRJ, previously described with respect to FIG. 102, makes sure the field is right justified so that the subsequently described math package can operate on it. Subroutine GETFLD retrieves the right justified value. Branch TRNFB4 determines if the field is blank and will insert zeros if it is. Otherwise, branch TRNFB5 will transfer the value to a field buffer. The program loops through TRNFB5 until all the characters have been transferred.

If the program is processing an absolute value, subroutine TRNABF, see FIG. 110, is called. Branch TRNAB5 transfers each of the characters in a manner described above with respect to subroutine TRNFBF. Branch NABF80 is then used for a transfer to the next available buffer, so there are two sets of characters and buffers.

Both branches of the program unite at branch CF1007 which determines the algebraic operator, i.e. add, subtract, etc. by retrieving the next character and stores the information in memory by calling on subroutine SAVEOP, see FIG. 111. After accessing SAVEOP, the program branches to CF1015 if a field or absolute value is identified, and calls subroutine TRNABF, previously described with respect to FIG. 110. Otherwise, the program will again access subroutine TRNFBF, described above. Upon reaching branch CFI017, the program will call the mathematical subroutine identified by the algebraic operator discussed above. The math subroutine will be discussed in more detail below. After completing one of the math subroutines, the program continues to branch CFI100 and calls subroutine FNDFLC to retrieve the field which will hold the calculated answer. The field is tested for sufficient space. If the answer is larger than the available space, the program continues to branch CFI101 and calls upon subroutine PVTFLD, previously described with respect to FIG. 101, to put the field on the screen and set a flag. This flag will branch the program immediately to CFI102. There is no need to right justify the number if an overflow condition exists, so subroutine RJFLD is bypassed. The overflow condition is checked in subroutine CHKOVF, see FIG. 112. This subroutine is a general routine that can be entered from other places in the program. If no overflow condition exists, the program immediately returns to a calling subroutine. If needed, branch OVFER5 sets the field upon the screen in reverse video and prints an appropriate error message by calling subroutine REVFLD, SETSCR, and PERMSG, previously described with respect to FIGS. 57, 72, and 70. Pressing any key will complete the INCHAR subroutine and allows the program to continue by clearing the message and correcting the field with subroutines CLR24 and CORFLD before returning to the subroutine calling PREVAL.

Starting with FIG. 113, the mathematic subroutines MADD, MSUB, MDIV and MMUL are described in more detail. All of the math subroutines call upon subroutine PREP, see FIG. 114, in preparation for performing the math functions. The first subroutine under PREP is CLRFPN, see FIG. 115, which clears memory for a floating point number. Subroutine FPIN, see FIG. 116, next verifies the validity of the number and converts it from a coded decimal character to floating point notation. The floating point notation is expressed as a mantissa and an exponent. The floating point notation of AUTOGRAMMER allows the operator use of 26 significant digits with an exponent power in the range of 128 to -127. Generally, the FPIN subroutine first clears the buffers and flags with subroutine CLEAR, see FIG. 117 and subroutine IBSCN is accessed, see FIG. 175. Decimal conversion is performed by subroutine ASCDC, see FIG. 118. The exponent is fixed and normalized by subroutines FIXE, CHKPN, and VCOPY, see FIGS. 119, 120, and 121 respectively, because of errors inherent with binary mathematics. Upon returning to the FPIN subroutine, the answer is placed in memory which has been cleared by subroutine CLRBUF, see FIG. 122. Generally, the subroutine of the floating point mathematic package are conventional, except that AUTOGRAMMER can process 26 significant digits and ten decimals places. Due to the number of permutations within each of the math subroutines a detailed description is impractical and only an overview will be provided. Increasing the execution time other than what is provided in App A and the flow charts. The division subroutine FPDIV, see FIG. 123, contains an error tracking routine FPDIV5 which sets up an error flag and prevents the program from stopping. The program continues to branch FD11 and calls subroutine LOAD, see FIG. 124, which sets up the parameters. Branches DIV0, DIVI, DIV2, and DIV3 convert the number into two binary numbers, one being the complement of the other. Subroutines XXADD and LEFT, see FIGS. 125 and 126, respectively, are called to add the binary numbers together and accomplish the division. Before returning, branch DIV7 calls subroutine STORO, see FIG. 127, which stores the calculated answer and any error flags in a register for later retrieval. The addition and subtraction subroutines, FPSUB and FFADD, respectively are illustrated in FIG. 128. These subroutines are the same, only the sign of the exponent is changed. The first subroutine is EXPCK, see FIG. 129, which checks the validity of the exponent. The ADSUM branch performs a binary addition and an exponent addition with the XXADD subroutine, previously described with respect to FIG. 125, and subroutine RIGHT, see FIG. 132. If an overflow results, the program branches to ADS1, and subroutine XXSUB, see FIG. 130, which does subtraction and normalization to bring the number back within range through a method of adjusting decimal points. Branch FPDIV5 is accessed to report the overflow error. Otherwise, the sign is stored through subroutine STORE, previously described with respect to FIG. 127, and the program returns. The multiplication subroutine, see FIG. 131, first equalizes the two numbers uses the branches FMOUR through FMUL7 to be multiplied by equating their exponents so the multiplication can be carried out. Then the program branches to FMUL8 for the actual digit-by-digit multiplication. Subroutine XXADD, previously described with respect to FIG. 125, performs the exponent addition. Once all the digits have been exhausted, the program branches to FMU15 and ADS2 which resolves the correct sign of the number after the multiplication. Branch ADS2 is also used by the addition-subtraction subroutines in FIG. 128. The program then stores the number and necessary flags before returning. This is a common ending to the subroutine which sets up the number for reconversion to ASCII added decimals.

Referring to FIG. 113, all of the algebraic operation subroutines continue to branch COMP which completes the math package with subroutine is FPOUT, see FIG. 133. Generally, this subroutine determines what kind of floating point number exists and converts that number to hexidecimal. During this process, subroutine ROUND, see FIG. 134, is called to round the number within the parameters of the math package and prepares it for conversion into human readable form. Trailing zeros are cleared off using subroutine CLEAN, see FIG. 135, and proceeding through the TRAIL branch. The program continues to branch FPRNT to check that the number is a positive, base ten number. Then the number is rounded off. Again, the value of the rounded number is checked to make sure a negative number has not been generated. If no errors have resulted, the number is transferred to a buffer by using subroutine XFERB3, see FIG. 136, and the program returns to subroutine FPOUT. Should a negative number result, the ROUND subroutine branches to XPRIN to convert the number to a positive value and then to a decimal using subroutine CONV, see FIG. 137, among others. The output is transferred to a buffer before returning to subroutine FPOUT. Once the number has been rounded off, the COMP branch shown in FIG. 113, is completed and the program exits from the main package. As previously stated, the INLOOP subroutine retrieves all of the fields present on the display screen including those characters which require special handling. After accomplishing this task, the program returns to the major subroutine ADDREC.

Referring to the ADDREC5 branch of the major subroutine described in FIG. 84, the program continues through subroutine TRNREC. Using the escape key at this point will return the program to INITAP through branch ADDREC6. The escape key retrieves the same record again and displays the menu. If the control key is used instead, the program branches to ADDREC5 to erase the display screen and start this part of the program over again in the manner just described.

The TRNREC subroutine, see FIG. 142, proceeds along the TRNREC5 branch through subroutine FNDFLC, see again the description of FIG. 56. FNDFLC finds the field specifications and checks whether the last field has been retrieved and whether there is some data in the field to be saved. The subroutine following FNDFLC is CHKSAV, described in FIG. 143, which checks the validations to identify whether the field is stored or non-stored and sets a flag accordingly. The next subroutine, TRNFLD, see FIG. 144, simply reads the contents of the field from the screen directly into the field buffer using subroutine VDREAD, see again the description of FIG. 29. The TRNREC subroutine then returns to ADDREC.

Returning to FIG. 84, the next subroutine in ADDREC is SAVREC, set forth in FIG. 145. Generally, a record is saved in sequential order, appending the record to the end of the data base file without concern as to its alphabetical order. The record number, however, is appended to the key file in numerical sequence so that a binary search can find the key value and the associated record number to retrieve the record from the data base. The primary purpose of the SAVREC routine is to place the key file in the correct sequence as each record number is entered. Building the correct sequence requires SAVREC to find the closest record number in the key file. One of the advantages of AUTOGRAM is that SAVREC locates the proper place for the newest or current record number in an expanding sequence with a high degree of accuracy and without performing a large number of time-consuming searches. SAVREC also takes into account a number of special circumstances. The program avoids unnecessary searching if the first or last record of the key file is identified. The program also allows moving either forward or backward through the key file under operator control if a large number of identical record numbers are identified.

SAVREC identifies how many records are in the current data base by directly reading the data base and locating the record last read. This is accomplished by accessing subroutines DIRRD2 and LOCATE, previously described with reference to FIGS. 80 and 81, respectively. The next subroutine, CREKEY, see FIG. 146, creates a file number to attach to the end of the key file record so that the data base record will correspond to the key file record number or key value hereinafter. Continuing down through the FNDNEN branch, the first record will be identified when the LOCATE subroutine retrieves a zero value indicating the absence of any input in the data base. For this special circumstance, the program proceeds down the FIRSTK branch. The program performs a hardward function DIRWR2 which places the first record directly into the data base. Subroutine transfer key, TRNKY1, see FIG. 147, places the newly created key value into a buffer. After the TRNKY1 subroutine, hardware function DIRWR directly writes the key value into the key file and writes the record on the floppy disk. Thus, FIRSTK branch generally performs a block move of memory, and then returns to the major subroutine ADDREC.

If the record is other than the absolute first one, the program follows the FNDNE1 branch. The first record number is read from the key file by the direct read subroutine DIRRD. If there is no error in reading the key file, the program continues down the FNDNE2 branch. Otherwise, the program loops back through the FNDNE1 branch.

The FNDNE2 branch calls upon the COMKEY subroutine, see FIG. 148. In the present embodiment, each record number is identified by three characteristics. This subroutine performs a character-by-character comparison of the key value just read and the key record value. The key value may then be higher, lower, or equal to the value of the key record. After completing the comparison, the key record value is marked accordingly for later identification by the program. If the values of the first character are equal, the COMKEY subroutine loops back to branch COMKEL. This allows retrieval of another character of the key record value so that COMKEY can eventually find a character which does not equal the character of the key value. If all the characters of the key value and current record value are equal, however, the program branches to the right and returns directly to SAVREC. If the character of the key value and the key record value are not equal, the program calls on branch COMKND. A low key value will directly return the program to SAVREC. If the key value is too high, the major subroutine ADDREC. Thus, the particular key value added is put in the appropriate position in the key file and the record is placed at the absolute end of the data base.

If the key value and the key record value are equal, or in other words, they are duplicate keys, then the program will follow the FND007 branch. Generally, new key records are read into the data base, shuffling previously read records down one position in the data base. The first subroutine called in this branch is LOCATE, see again FIG. 78, which retrieves the record number. The record is written into the data base as it proceeds through branch FNDNKL by supervisor function direct write DIRWR2. The program continues through branch FNDNE7 which performs a direct read to identify the record number just written by DIRWR2; sets buffer 1 equal to buffer 2 through subroutine MB1B2, as set forth in FIG. 150; sets the key record equal to buffer 1 through subroutine MKRB1, previously described with reference to FIG. 149; performs a direct write through DIRWR; and finally, sets buffer 2 equal to the key record through subroutine MB2KR, as set forth by FIG. 151. The program continues to loop through branch FNDNE7 until the last record in the data base is reached. Upon this event, branch FNDN99 is followed to perform a direct read with hardware function DIRRD; set buffer 1 equal to buffer 2 through subroutine MB1B2; sets the key record equal to buffer 1 through subroutine MKRB1; and finally, directly writes through supervisor function DIRWR, as described immediately above.

If the key value is higher than the key record value, the program branches from FNDNE2 to FNDNEA. The first function of the FNDNEA branch, DIRRD, performs a direct read. Based upon the identified value, three possible branches may be followed. The program will branch to FNDEND if the last record has been read and the program is now at the end of the data base. If the program is at the end of the file, the program branches to FNDEND to follow the subroutines previously discussed and eventually return to the major subroutine ADDREC. If the program is not at the end of the file and a valid record is read, the program branches to FNDENB and uses the subroutine COMKEY, previously discussed with reference to FIG. 148, to determine whether the key record value is equal to, less than, or greater than the data base record number. If the values are equal, the program branches to FND007 to follow the same sequence of subroutines previously described in the paragraph above. If the key record value is less than the data base record number, the program branches to FNDSTR which again takes the program to branch FNDNE7. The subroutine of the FNDEN7 branch has been previously discussed in the above paragraph. To reiterate, branch FNDNE7 places the key record in the beginning of the data base record and shuffles previously written records down one position in the data base. If the key record value is greater than the data base record number, the program calls subroutine COMMM, set forth in FIG. 152. The key record value and the data base record number are compared to determine whether or not they are greater or less than ten records apart and identifies the minimum and maximum value. If the values are ten records or less apart, the program branches to FNDSEQ which performs a sequential search.

The FNDSEQ branch performs a direct read DIRRD to check if this is the last record of the sequence. If it is not the last record, the program continues to branch FNDSE3 to check if the key values are equal. If the values are not equal, the program branches to FNDNE4 and then to branch FNDNE3 to identify the low mid-record. The low mid-record is a number half-way between the current minimum and maximum value. This is a self-correcting feature of the program which allows the sequential search to be modified by backing up a variable number of records before sequentially searching forward again. The low mid-record formula backs the record value past the last binary search value, which would be a maximum of sixteen records. This function is performed by the FLMIDR subroutine, see FIG. 153, which consists of branch FLMID and subroutine DIVHL, seen in FIG. 154. A comparison of the new minimum and maximum value is performed by subroutine COMMM, previously discussed with reference to FIG. 152. If these new minimum and maximum values are still less than ten records apart, the program branches to FNDSEQ, completing the search sequentially.

The FNDSEQ branch contains three options for the program to follow after performing a direct read by hardware function DIRRD. If an error results, the program goes to FNDSE3 to use the COMKEY subroutine in the manner previously described with respect to FIG. 148 and properly identify the correct record. If the key file value is lower than the data base number the program branches to FNDNE4 and FNDNE3 to retrieve another record from the data base. If the key file number was higher than the data base number, the program proceeds to branch FNDSE5 through the LOCATE subroutine, see again FIG. 81, to identify the position of the program in the record data base and increment the file key value to move one record ahead. This procedure avoids the use of the hardware function called "read next record" by this program and in its place only direct reads are used. The program then branches to FDISNF if all ten records have been sequentially searched from the maximum record and the correct position has not been identified. On the other hand, if the record is found, the program branches to FNDSE6 and performs a direct read, DIRRD. The program will then branch to FNDSE5, if a deleted record is identified. The program replaces the first character in a deleted record with an error flag. Reading the error flag will branch the program to FNDSE5. If a deleted record is not identified, the program continues through subroutine COMKEY, described with respect to FIG. 148, and performs the comparison between the key file value and the data base record number. If the data base record number is too high by comparison to the key file number, the program branches to FNDNKL and the record is inserted and the other records in the data base are shuffled down one position as previously described in the discussion regarding branch FND007. If the values are equal, the program branches to FND007 which indicates that it's a duplicate key and the record is inserted next to the record read from the data base and the other records are shuffled down. If the value is too low the program branches back to FNDNE5 and the program proceeds in the manner just described. This will complete the recording of the current record.

Returning back to our decision point at branch FNDNE3 of SAVREC, if the minimum and maximum values were not less than ten records apart, the program will continue to branch FNDNEC. After a direct read by DIRRD, the program loops back to FNDNEC if the record is identified as a deleted record. Otherwise, the program branches to FNDNED and calls subroutine COMKEY, see again FIG. 148, to compare the new value just read. If the values are the same, the program branches to FND007 and performs the functions previously described. If the record value is too high, the program continues down through FNDNE4 and branches back to FNDNE3. If the record value is too low, the program branches to FNDNE5 to compute a new high mid-record through subroutine FHMIDR, see FIG. 155, and then performs a comparison of the minimum and maximum value through subroutine COMMM as previously discussed. If the minimum and maximum values are less than ten records apart, the program branches to FNDSEQ and a sequential search is performed as previously described. Otherwise, the program branches to FNDNEE and the new maximum mid-record number is read by DIRRD. If it's a deleted record, the program loops back through this branch to read the next record. If the mid-record number is at the maximum value, the program branches back to FNDSEQ to perform a sequential search as previously described. If the number is neither a deleted record nor the maximum mid-record number, the program branches to FNDNEF and performs a subroutine COMKEY to compare the number against the value of the key record. If the values are equal, the program branches to FND007 and performs the function previously described. If the value is too high, the program branches to FNDNE6 to perform the functions previously described as the standard loop is reiterated. If the value is too low, the program continues back to branch FNDNE5 to find the next high mid-record as just described.

There are several important advantages incorporated in the SAVREC subroutine. First, the subroutine is capable of handling Non-unique key values, such as when duplicate records are read. Second, the program uses a combination of a binary search and a sequential search. This allows the program to quickly search for records in the data base with nearly complete accuracy. Only if multiple duplicate records existed of a quantity higher than the arbitrary cut-off number before a sequential search is chosen, and the statistically slim chance of finding the absolute first data record as the first record read could the program locate a duplicate record instead. The program also provides for a control repeat function which allows the programmer to push the program back or forward to find the very first duplicate data base record. In nearly all instances this self-correcting subroutine performs flawlessly.

When the program leaves the SAVREC subroutine after saving the record, it returns to branch ADDREC5 of the major subroutine ADDREC, clearing all the information from the screen. In turn, the ADDREC subroutine is exited through branch ADDREC6 which returns to display the menu.

Returning to the INITAP routine in FIG. 74, the second major subroutine available on the menu is DELREC, described in FIG. 156, which deletes a record. The first subroutines called are SETTIT and ARAMVD, previously described with respect to FIGS. 85 and 86, which sets the title and places the RAM memory input on the display screen. The program proceeds through the branch DELRE0 to use subroutine INKEY1, see FIG. 157, which prompts input from the operator to identify the key field. The DELRE0 branch loops to accommodate the entry of more than one field. If an escape key is inputted at this point, the program returns to the DSMENU branch to display the menu upon the screen. If the return key is inputted, the program continues with the DELRE3 branch. After finding the record through FNDREC, see FIG. 162, the program continues through branch DELRE3. The subroutines SETSCR, CLRPRT, and INCHAR, previously discussed with reference to FIGS. 72, 30, and 52, respectively, sets the scroll to protect the bottom line, clears the bottom line on the screen, and prints out a message that requests whether the programmer desires to delete the record. Answering this decision point in the affirmative will continue the program through a second pair of subroutines CLRPRT and INCHAR to reiterate the question and check the response. A second affirmative answer continues to program to branch DELRE9 to delete the record with two DIRWR commands. The program then returns to the beginning of DELREC. If the initial decision point is answered in the negative, the program continues through branch DELRE4 and loops back directly to the beginning of DELREC. At the initial decision point, the programmer may also input a delete the previous record command and the program flows through branch DELRE5 and uses subroutine RDNREC, described below, if the answer previous record is given at the decision branch, the program flows to branch DELRE6 which directs the program to perform all the functions of branch DELRE3, previously discussed immediately above.

The RDNREC subroutine, set forth in FIG. 158, reads the next record in the data base, and checks the first field flag. The first entry in the data base is a special flag which alleviates the problem which would occur in most micro-computers where the first record is actually registered as zero in the data base, the first record starting at the zero position of the data base. If this is the first record in the data base, RDNREC branches to FNDNRC to print the first record and display a message stating that this is the first record in the data base. If this is the last record in the data base, the program continues through the DEDMSG subroutine, see FIG. 159, and returns to DELREC. If a valid record has been read, the program branches through RDR03 and RDR05 to read that record and return to the major subroutine DELREC.

Returning now to INITAP in FIG. 74, the third major subroutine on the menu is MODREC, which allows the operator to modify a record. As described in FIG. 160, MODREC sets the title and transfers the RAM memory onto the display screen by calling subroutines SETTIT and ARAMVD, previously described with FIGS. 85 and 86, respectively. The program continues through branch MODRE5 and calls subroutine INKEY1 to retrieve the value of the first field in the manner previously described with reference to FIG. 157. If the retrieved value is the escape key, the program branches to DSMENU which displays the menu once again upon the display screen. If the value is to modify the previous record, the program branches to MODPREV and calls upon subroutine RDPREC, see FIG. 161. The RDPREC subroutine takes into account the special circumstance where the record being read is actually the first record on the data base by directly reading the record through DIRRD2 and subroutine FDIS90 which branches into subroutine FNDREC, described below. Subroutine DEDMSG, described earlier with regard to FIG. 159, displays a message and then returns to branch MODRE7. In a similar fashion, if the value indicates modify next record, the program branches to MODNXT and calls subroutine RNDREC, which has been previously explained in FIG. 158. Again, the subroutine returns to branch MODRE7. If the value is the special circumstance of a return command, the program continues straight for subroutine FNDREC, see FIG. 162, which transfers the record out of the data base and puts it onto the display screen using subroutine TRNREC as previously discussed with reference to FIG. 142. FNDREC further consists of subroutine MB2KR which retrieves the data from buffer 2, converts it to a key record, and displays it on the display screen through subroutine FNDDIS. The program then proceeds through the FNDRE5 branch to determine if a partial search is to be performed. The partial search compares the values of the records to determine if they are equal or a duplicate key. If the records are not a duplicate key, the program continues to the next level of direct read, DIRRD2 and again performs a partial search to determine whether the records are equal. If they are, the program continues through subroutine TRNRVD, as described in more detail in FIG. 163. The TRNRVD subroutine reads the records into RAM memory and then performs a comparison by calling subroutines FNDFLC and CHKSAV previously described with reference to FIGS. 56 and 143, respectively. When the program returns to MODREC, referring to FIG. 160, the program will continue from branch MODRE7 through subroutine INLOP5 if there is additional data which is to be inputted and used in performing the search. For instance, in a data base directory, the name of the person alone, both the name and address, or any other combination could be used to perform the search.

Returning now to FIG. 74, the fourth major subroutine on the menu of INITAP is DISREC. FIG. 164 provides a more detailed description of DISREC. The title is set on the screen by subroutine SETTIT and the RAM memory is transferred to the screen as well through subroutine ARAMVD. As the program proceeds through branch DISRE5, subroutine INKEY1 retrieves the value from the first field of the record. If the value is a read previous, the program branches through DISPRE and calls subroutine RDPREC which reads the previous record in the manner previously described with reference to FIG. 161. If the value is a read next, the program branches through DISNXT which calls subroutine RNDREC and returns back to branch DISRE5 after reading the next record. If the value was the F2 key, the program branches through DISPRT and calls subroutine SCNPRT, previously described with reference to FIG. 46, before branching back to DISRE5. If the value is the escape key, the program returns to INITAP and prints the menu upon the screen. If the value is a left arrow key, the program branches through DISRE7 and performs a key search rather than a general data search. The subroutine on branch DISRE8 is FNDREC, as earlier described with reference to FIG. 162, which enters all the data found in the various fields and locates the record based upon all of that inputted information. Then the program returns to branch DISRE5 for another search. On the other hand, if a specific key search is to be performed, the program will go through subroutine LASTFN, in the manner referenced in FIG. 91. The program proceeds through DISRC4 and calls branch INLOP5, of subroutine INLOOP previously described with reference to FIG. 87, which inputs the data from the reminder of the fields so that a general purpose search based upon something other than the key value can be performed. After branch INLOP5, the programmer is prompted to request either a read next, or a read previous command. If the record has been deleted, the program loops to find the next previous record. Otherwise, the program flows through branch DISRC8 and compares the records to see if they are equal. If they are not equal, the program goes back to branch DISRC6. If the records are equal, the program branches to DISRC9 and calls subroutine TRNRVD which transfers the RAM memory to video and takes the program back to branch DISRC4. The TRNRVD subroutine has been previously described with reference to FIG. 163. If the display next command has been inputted by the programmer, the program branches to DISRC3 which reads the next record and loops back through DISRC3 if the record has been deleted. Otherwise, the program branches through DISRC5 and performs a comparison of the records by calling upon subroutine RECCOM, see FIG. 165. If the values of the records are equal, the program flows to branch DISRC9 as previously described. If the values are not equal, the program branches back to DISRC3 to read the next record. If there are no more records in the data base of this type, the program will branch directly from DISRC3 to DISRC9 and eventually return to DISRC4. When more than one field is specified for the search, one can run out of records of all types. Thus, no records remain in the data base at all. If the latter occurs, the program will branch to DISRCB and eventually to DISRC4. The last record is then left on the screen. The programmer can also request a record transfer which is performed by subroutines CLRMM2, TRNREC and RDNREC, previously described with reference to FIGS. 6, 142, and 158 respectively, which performs the record transfer, reads the next record, screen dispays, and branches to DISRC1 to do a record comparison. Based upon that comparison the program determines whether to move forward or backwards in the data base records and return to branch DISRC3 or DISRC9.

Referring back to FIG. 74, the main routine INITAP has access to a final major routine which simply ends the AUTOGRAM program by exiting through step END99. This subroutine, previously described, closes the data bases, clears the screen, restores the break key, and terminates the program.

From the above, it is seen that there has been provided a computer program, in particular an automatic program generator, which fulfills all of the objects and advantges set forth above. The automatic program generators of the present invention create special application programs using a visual creation process which requires no textual preparation on the operator's part. The application programs are generated in a fraction of the time needed to create application programs by means of conventional programming techniques. The application program is developed in machine language without requiring a user's input program and runs independently of other programs.

It has been further demonstrated that the present invention provides automatic program generators which develop their own internal language or syntax to develop application programs. Furthermore, the need to restart a program due to errors caused by either the operator or machine are alleviated by automatically returning to the last routine in the program if an error results. In fact, sections of program code are preempted if the code was inadvertently accessed by another section of the program. Also, the application's programs are capable of performing algebraic operations using floating point notation with twenty-six significant digits and ten decimal places and can more efficiently search for and sequence data records in a data base file.

It should be understood that the present invention is not limited to the precise structure of the illustrated embodiments, it being intended that the foregoing description of the presently preferred embodiments be regarded as an ilustration rather than as a limitation of the present invention. It is the following claims, including all equivalents, which are intended to define the scope of the invention.