SOFTWARE OPTIMIZATION SYSTEM

Abstract: A system for reading existing program source codes (101) which may be initially stored in computer memory, hard disk storage devices, on floppy disk storage device, diskettes, or virtually any other computer readable medium. A table lookup may be used to convert the native source code (103) into a pseudo code form (104) for writing out of such code as an interim source code file into virtual memory (105) to be used for conversion and manipulation. The source code in the pseudo format is processed in five (I-V) phases resulting in a new program source code with appropriate instructions to call library common functions for the new system stored in the library as created by the optimization system. In addition, various files, data elements and work space allocations are normalized, i.e. referred to by the same names by all source code. During the optimization process, the user may interactively change the names of files, any of the attributes of the data elements (106) which will be reflected for all occurrences of the element and workspace definitions. In addition, work space allocations are given a unique name by the system.

Description: SOFTWARE OPTIMIZATION SYSTEM BACKGROUND OF THE INVENTION 1. Field of the Invention The Field of this invention relates to a computer program optimization system which results in code reduction and standardization. More specifically, the instant invention relates to a computer system which evaluates existing software and performs vertical, horizontal and sequential synchronization on the source code, utilizing an interim pseudo code to create new systems library and a program source code file. 2. Related Art Prior art systems relate to code conversion systems, including compilers and language translators. However, such programs take data as it is and in sequence without an evaluation of the use of individual variables. Usually such conversions are performed in sequence one program at a time. Thus, there is no evaluation of the several programs used in a systems group against each other. It is an object of the instant invention to provide a computer program optimization system which evaluates multiple program source code files as a whole. It is a further object of this invention to provide a computer program optimization system which generates uniformly named variables which occupy the same physical location or possess the same value profile. It is a further object of this invention to provide a computer program optimization system which permits interactive modification of element attributes during the optimization process. It is a further object of this invention to provide a computer program optimization system which consolidates all repeated program code segments into a library. The instant invention addresses the usage of various elements, variables and structures in an entire software system and consolidates all redundant information. In addition, other elements are identified by physical location and uniformly named. BRIEF DESCRIPTION OF THE INVENTION The instant invention reads existing program source codes which may be initially stored in computer memory, hard disk storage devices, on floppy disk storage device, diskettes, or virtually any other computer readable medium. A table lookup may be used to convert the native source code into a into a pseudo code form for writing out of such code as an interim source code file into virtual memory to be used for conversion and manipulation. The source code in the pseudo format is processed in five (I-V) phases resulting in a new program source code with appropriate instructions to call library common functions for the new system stored in the system library as created by the optimization system. In addition, various files, data elements and work space allocations each of which occupy the same space with other such files, elements and work space allocations are normalized, i.e. referred to by the same names by all source code. During the optimization process, the user may interactively change the names of files, any of the attributes of the data elements which will be reflected for all occurrences of the element and workspace definitions. In addition, work space allocations are given a unique name by the system. The first phase of the computer optimization system is a vertical synchronization process which identifies all individual file name references, data element references and workspace allocations within every record type, within every file representative of program source code. A common name is assigned to each file, element or workspace by physical position within a record within each of the files. The process also creates various cross-reference files that are structured to be accessed either sequentially or randomly as required. The file, common element and workspace names replace the original names used in the original program source code. During vertical synchronization a user may interactively specify specific file names and definitions for a particular element which then becomes the standard for all the source codes examined by the system. If no specific designation is made, the system automatically selects the first unique name it encounters within the software to identify the physical position of a file or specific data element as the new standard definition. The system then generates a file name, cross-reference file and an element cross- reference file to identify each file and data element and the assigned name. Work space allocations are also identified and each unique location assigned a specific name. In phase II the system implements a horizontal synchronization process which formats all program instructions in the interim code into standard syntax format. This permits an exact match between given instructions within the source code according to a uniform or standard syntax format. The program source code written in the standard syntax of the interim format is temporarily stored in virtual memory for later use during the optimization process. In phase III, a sequential synchronization process scans all interim program source code instructions to determine if there are at least two or more source code instructions in any program source code that qualifies as a potential common function. Potential common functions are identified as that code which resides between program labels although it is clear that other designations could be used, such as instruction sequences that are bounded by instruction pairs, e.g. start and end of a conditional statement. Codes so identified are qualified as a potential common function, and then matched against other potential common functions within a potential library common function file. If not present, the functions are then stored in the Potential Library Common Function File with all other potential library common functions. In phase IV, the temporary copy of each of the modified program source codes for each program source code file in the system is written into new files with all redundant instructions as stored in the potential library common function file replaced with a call to the particular function in the common library file. The particular potential library functions so identified are then stored in a current systems library file. The selection of which potential common library functions are to be replaced with a call and stored in the current systems library file is accomplished by comparing the function against a Function Sequence File to determine if the particular common function being analyzed is used more than once. A Program Function Identification File contains data which determines where duplication occurs in a program and, more particularly, at what position within the program such duplication occurs. Thus, the location of the call and removal of the code segment can be accomplished for all segments which are used more than once. Segments which are not used more than once remain in place and are not moved to the current library. In Phase V, when the modified source code has been restructured, and it is vertically, horizontally and sequentially standardized, redundant program functions are identified and added to the new system library file. This results in source code which has no redundancy. That is, no two or more instructions that are identical exist more than once anywhere within any program in the system. A significant increase in efficiency and reduction of code are achieved. Similarly, all of the various data elements which occupy the same location use a common identifier in each of the various source code files in which they are referenced. Phase V concludes with a conversion of the interim program code into its native format. Alternatively, the user may automate the change of element attributes. That is the user may command the system to automatically make the changes input by the user and automatically post the changes to the interim source code or automatically make its own name changes as determined by the System. As to those elements where the user has not made any changes the system automatically selects the attributes of the first occurrence of the element and posts that elements attributes to all other references to the same location. If an interim code was used, the system then automatically converts the interim code to native code and an audit trail report of all changes made during the automatic change process is printed. On completion of the optimization of the computer code, database specifications, screen and print specifications, and conditional logic specification from the interim source code are determined and these specifications are stored in separate databases. The system provides additional options, including a review of file and element definitions and the option to selectively convert, scan or repair programs analyzed. BRIEF DESCRIPTION OF THE DRAWINGS Figure 1 is a flow chart of the overall optimization system. Figures 2 A through 2L are a flow charts of the Vertical Synchronization System. Figures 3 is a flow chart of the Horizontal Synchronization System. Figure 4 is a flow chart of the Sequential Synchronization System. Figures 5A and 5B are flow charts of the library common function evaluation. Figures 6A and 6B are flow charts of the conversion of the optimized code into native format. Figures 7A through 7D illustrate library common function segmentation. Figures 8A through 8Z are selected user screens for the Analyzer option. Figures 9A through 9K are flow charts of the manual repair of file, element and workspace element definitions. Figures 10A through IOC are user screens for the manual repair. Figures 11 is a flow chart of the Conversion option. Figures 12 A through 12B are user screens for the conversion option. Figures 13 is a flow chart of the cost analysis function. Figures 14A through 14C are user screens for the cost analysis function. Figure 15A through 15B are schematics of I/O Records. Figure 16A through 16D are schematics of working storage Records. Figure 17A through 17D are schematics of common function Records. Figure 18 is a schematic of the Parse Table. Figure 19 is a flow chart of the print report option. PREFERRED EMBODIMENT OVERVIEW OF PREFERRED EMBODIMENT All software programs comprise three basic parts. These include an I/O Area, Working Storage Area's and Procedural Logic. Within each of these there are various elements used by the programming Program. In each of these parts there are logical file names, work area allocations, and data elements such as variables and constants which are stored in data files, temporarily stored in Working Storage Area's, and referenced in the procedural logic. The instant system standardizes names of files, data elements and work storage references and stores common procedural program code segments in a library. The instant invention is implemented on an IBM P.C. with disk storage and memory. It is distributed on diskette or other computer readable memory. With reference to the drawings, Figure 1 is a flow chart illustrating the various phases of operation of the preferred embodiment of the invention. There are five basic phases of operation commencing with vertical synchronization, step 100, Phase I. On completion of Phase I, Horizontal synchronization, step 200, Phase II, is commenced. On completion of Phase II, Sequential Synchronization 300, Phase III is commenced. On completion of Phase III, new program source code is created 400, Phase IV. On completion of Phase IV, a new current systems library is created 500, Phase V, and new program source code is stored as new native code. Figures 2 A through 2L illustrate in more detail the various steps of Phase I. The system operates on program source code files which are related in some manner, such as a financial management system which includes an accounts payable module, an accounts receivable module and so on. The relationship exists in that each of the program source code modules access common data files or use identically formatted work areas. These common data files can include client data files, customer data files, inventory data files, and the like each of which contains various data fields and the defined work area structures. The programs access data elements by defining variables and constants by name and by various attributes such as length, type and so on. In the case of working storage, formatting may also be included such as when a display or printout of data is required. The optimization commences by selecting an option as shown in Figure 2A, step 101. If Option 1 is selected, step 102 the optimization process commences by reading the program source code files from the current system library for the related group of program files, step 103. Each of the source code files including the function libraries are converted into an interim code which may be in either a native or a pseudo format, step 104 as shown in Figure 2B. A pseudo format has been selected in the preferred embodiment as an interim step to simplify the program code for the instant invention. This permits the software of the instant invention to read different program languages convert the instructions to the pseudo code and perform the optimization on the pseudo code without the necessity of rewriting the instant software for the optimization of different program code languages. It should be noted that the invention disclosed herein can operate directly on the native source code without the need to convert to a pseudo code by simply writing the software to include operations on the native language reserved words. The pseudo code is code which substitutes the keyword or reserved words of any language instruction with a token word. For example a MOVE instruction is converted in the pseudo code to MV. Several different kinds of MOVE instructions are converted sequentially in order of complexity as MV1, MV2, etc. It is clear that a corresponding token must be established for each instruction keyword or reserved word and placed in a table for use in the conversion from native to pseudo code for the target native code. This is accomplished by simply replacing each reserved word on reading the native code with the corresponding pseudo code word for that function and writing the revised code as a new file. In the event the pseudo code is not used, the original source code is written out to a new interim file in the native code for optimization to avoid corruption of the original native code during the optimization process. As shown in Figure 2B, the system writes out all pseudo code files into an interim source code file into virtual memory, step 105. This places all source code instructions and data in a specific physical location in such memory which is accessible either sequentially or randomly. After converting all source code files the user is presented with the additional options as shown in Figure 2C, step 106. Option 1 is a continuation of the Optimization process. The remaining options permit the user to select an intermediate option as will be discussed hereafter. If Option 1 is selected, step 106, the system commences reading the interim source code files, steps 108-110. Referring to Figure 2D, the system reads the source code files and determines the logical file name used to access each file and creates a File Name Cross Reference File of logical names and related physical file names. The File Name Cross Reference File is stored on disk, step 108. The user may as an option modify the logical name used by the system for any file. This modified name is stored as the logical name for the first occurrence of the reference to the physical file as set forth in the File Name Cross Reference File. Each instruction in each source code file or module is again read from the interim source code files and its type determined. Those instructions which operate on a data element are analyzed and the data element identified. The name and other attributes of the data element are determined and an Element Cross Reference File containing each data element by name and its associated attributes is created , step 109. The Element Cross Reference File is stored on disk and contains at least the following information regarding each data element: 1. SOURCE FILE NAME 2. RECORD TYPE 3. ELEMENT NAME 4. ELEMENT LENGTH Each instruction in each source code file or module is again read from the interim source code file and its type determined. Those instructions, which define work space allocations are analyzed and the work space identified. The workspace is analyzed by structure and a Work Space Common Occurrence File for each workspace definition is created, step 110. The Work Space Common Occurrence File contains at least the following information regarding each work space allocation: 1. THE OCCURRENCE NUMBER 2. THE SIZE OF THE WORK SPACE IN CHARACTERS 3. THE NUMBER OF LINES ALLOCATED FOR THE WORKSPACE 4. THE SEQUENCE OF EACH IDENTICALLY DEFINED WORK SPACE 5. ANY SPECIAL FORMAT INFORMATION The system provides for interactive communication with a user, who may indicate that a Where Used Report is or is not to be generated. With reference to Figure 2E, a File Where Used Report for logical file names, may be selected for display or print by the user. A File Where Used Report is a report of the contents of the File Name Cross Reference File with information sorted by physical location. This permits the user to evaluate which of the various logical file name references refer to the same physical file. If the user indicates that such a report is required, step 111 , the system prints out a report, step 112. The user may then examine the report and define new logical names for selected physical files. On review of the File Name Where Used Report the user may enter search information in a Parse Table, Figure 2F. If such information, step 113, is entered the system searches for files matching the Parse Table, step 114. The system also searches for files by name for those files which are not selected by the Parse Table, step 105. If the user defines a new logical name, step 116, the new name is substituted for the first occurrence of each unique file in the File Name Cross Reference File, step 117. Uniqueness is determined by the actual name of the file referred to by the logical file name. Multiple unique logical file names may be selected by the user for change and the user is given the opportunity to change the next physical file name step 118. On processing the last file name, the system goes to the next stage, step 118. An Element Where Used Report, Figure 2G, may be selected for print by the user, step 119. An Element Where Used Report is a report of the contents of the Element Cross Reference File with information sorted by physical location. This permits the user to evaluate which of the various data elements are stored in the same physical location. If the user indicates that such a report is required, the system prints out a report, step 120. The user may then examine the report and define new attributes for selected variables. On review of the Element Where Used Report the user may enter search information in Parse Table, step 121, as shown in Figure 2H. If such information is entered, the system searches the Element Cross Reference File for the data elements which match the Parse Table, step 122. The system also searches for any data elements for which no selection was made by the user, step 123. These element definitions may be a change by the name, type or length or any other attribute of the data element. In the case of a six byte date, for example, the user may wish to change the length to eight bytes in order to accommodate a four byte year such as the year 2000. If the user defines a new name or new attributes, step 124, the new data is substituted for the first occurrence of each unique data element in the Element Cross Reference File, step 125. Uniqueness is determined by the physical location of the data element in the virtual memory. Multiple unique data elements may be selected by the user for change and the user is given the opportunity to change the next element name or attributes, step 126. On processing the last file name, the system goes to the next stage, step 126. As shown in Figure 21, a Work Space Where Used Report for work space information, may be selected for display or print by the user, step 127. A Work Space Where Used Report is a report of the contents of the Work Space Common Occurrence File with information sorted by physical location. This permits the user to evaluate which of the various work space allocation parameters require change. For example, if a data element size is changed, the corresponding size of a work space may also require change. If the user indicates that such a report is required, step 127, the system prints out a report, step 128. The user may then examine the report and define new attributes for selected workspace parameters. On review ofthe Work space Where Used Report the user may enter search information in a Parse Table, step 129, as shown in Figure 2J. If such information is entered, the system searches the Work Space Common Occurrence file for common work spaces which match the Parse Table, step 130. The system also searches for any other Common workspace definitions for any workspace allocations for which no selection was made by the user, step 131. The essential difference is that work space is searched by its profile. These new definitions may be a change in the format, type or length or any other attribute of the workspace parameters. If the user defines a new name or new attributes, step 132, the new data is substituted for the first occurrence of each unique work space in the Work Space Common Occurrence File, step 133. Uniqueness is determined by the form of the workspace allocation. Multiple unique workspace definitions may be selected by the user for change and the user is given the opportunity to change the next work space definition, step 134. On processing the last work space definition, the system goes to the next stage, step 134. Referring to Figure 2K, the interim source code is checked and each logical file name is compared with the File Name Cross Reference File. Each reference to the same physical file name is changed to the logical name of the first occurrence of the logical file name associated with the same physical file as set forth in the File Name Cross Reference File, step 135, as determined by the system or selected by the user. The interim source code is again checked and each data element name is compared with the Element Cross Reference File. Each reference to the same element in the same physical location is changed to reference the name and attributes of the first occurrence of the data element as set forth in the Element Cross Reference File, step 136 as determined by the system or selected by the user. The interim source code is again checked and each work space allocation is compared with the Work Space Occurrence File. Each reference to the same work space in the same format is changed to reference the parameters of the first occurrence of the work space definitions as set forth in the Work Space Occurrence File, step 137 as determined by the system or selected by the user. However, the user cannot select a new workspace name . The system creates a new reference name for each unique Work Area, step 137, in the following format: WS- ooo-cccc-llll-sss, where "ooo" is the occurrence number, i.e., the first occurrence of the same work space allocation (ooo=001 and so on), "cccc" is a four digit number representing the size of the work space in characters, "1111" is a four digit number representing the number of lines of work area, and "sss" is a three digit number representing the sequence of lines of workspace allocated. That is, the order of identical work space allocations defined in sequence. The information required regarding the format of the Work Area is derived from the Work Space Common Occurrence file which defines each such area. The maximum sequence number is an indication of the largest number of work space allocations in any program sequence. Certain programs may overlap in all or part of the Work Area allocations. This means that if program 1 uses work space allocated in sequence 001 through 006, and program 2 uses workspace allocated in sequence 001 through 003, each program will utilize the same physical space in sequence 001 through 003. Program 1 of course uses additional space 004 through 006. Since the programs run at different times this use of the same work area does not create any conflict, but simplifies the code with standard definitions with equivalent work space used by different programs. The name created is substituted for each reference allocating the work area in sequence within each program step 138. This means that each work space name has the attributes of the work space built into the name and makes future maintenance less confusing. The user is provided an option to reprint the File Name Where Used Report for the revised file names, step 139. On an affirmative selection, the revised File Name Where Used Report is printed, step 140, as shown in Figure 2L. In Figure 2L, the user is then provided an option to reprint the Element Where Used Report for the revised data element names and attributes, step 141. On an affirmative selection, the revised Element Where Used Report is printed, step 141. The user is also provided an option to reprint the Work Space Common Occurrence Report for the revised workspace allocations, step 143. On an affirmative selection, the revised Work Space Common Occurrence Report is printed, step 144, and Phase I ends, step 145. While each Phase is indicated as sequentially following the other, this need not occur at the same time. That is, each Phase may be executed independently as indicated in options to be discussed hereafter. However, to the extent that each independent phase requires data generated by a previous phase, they should be executed in sequence. However, a user could elect to only make the names uniform throughout the programs and thus terminate at Phase I. Alternatively, perhaps only the size of certain variables is to be changed and this can be accomplished by making the appropriate attribute changes in Phase I. In Phase II, Figure 3, all source code files are scanned and restructured to a standard syntax format, step 201. In the preferred embodiment, that format is a single space between instruction words and no spaces between parenthesis and words bound by the parenthesis. Accordingly, excess or multiple spaces are removed so that space formatting is consistent for all words in the source code instructions. This makes comparison of instruction lines faster as syntax need not be examined at each line. The restructured interim code is then stored in virtual memory, step 202. The interim code now has uniform logical file names for the same file, data element names for the same data location, and the same reference name for workspace allocations. In Phase III, as shown in Figure 4, all interim program source code instructions are again scanned, step 301. Selected segments of code are examined to determine if the segment or any sub-segments qualify to be potential common library functions, step 302. In the preferred embodiment, the particular code segments examined are all segments which are positioned between program instruction code labels. Such code is parsed into sequential segments based on the series (N-l+N-2..+N-(N+l)) where N is equal to the number of code lines in the original segment and the result is a positive number greater than 0. This includes all sequential lines of code of at least two lines each, that is, as shown in Figures 7A through 7D. If a segment of code between two program labels is two instructions long, then one segment 1 qualifies to be a potential common library function, Figure 7 A. If three lines of code are between program labels, then there is one three line segment 2, two of the two line segments 3 and 4, for a total of (2+1) three segments which qualify to be potential common library functions, Figure 7B. If four lines of code are between program labels, then there is a four line segment 5, two three line segments 6 and 7, and three two line segments 8, 9 and 10, for a total of (3+2+1) six code segments each of which qualify to be potential common library functions, Figure 7C. Finally, if five lines of code are between program labels, then there is a five line segment 11, two four line segments 12 and 13, three of the three line segments 14, 15 and 16, and four two line segments 17, 18, 19, and 20, for a total of (4+3+2+ l)ten segments which qualify to be potential common library functions, Figure 7D. All code segments must be sequential. Referring again to Figure 4, on determination of the various segments which are potential common library functions, each such segment is compared against the segments already stored as potential common library functions in the Potential Common Library Function File, step 303. Each segment which has not been previously stored as a common library function, that is, it is not already present in the Potential Common Library File, is stored in the potential common library file, step 304 . Phase III exhibits significant storage activity and the system tends to slow down initially. As more potentially common functions are stored in the library, the speed of the system increases in proportion to the number of segments found in the library. For each segment which is found, the program file name and the starting and ending line numbers for the instruction segment are determined and stored in a Program Identification File, step 305 and Phase III ends, step 306. Phase IV commences, as shown in Figure 5 A, by reading data stored in the Function Sequence File and the Program Function Identification File, step 401. The Function Sequence File is compared with the Program Function Identification File for the number of occurrences of segments which are located in the Potential Common Library Function File, step 402, and a determination made as to those segments which are called more than once. If any segment is called more than once, it qualifies as a common function, step 403. All common functions are copied from the Potential Common Library Function File to the Common Function Library, step 404. In Figure 5B, all Interim source code is read from virtual memory, step 405 and redundant instruction segments (i.e., that which are used more than once) are removed from the source code, step 406. A single line of call code is inserted in the place of the removed code to call the respective code segment from the systems library, step 407. The revised program source code is then written to the program file on hard disk, step 408. The common functions are compared to the system library to determine if the segment was previously saved as a common function, step 409. If not, it is stored in the system library, step 410 and phase IV ends, step 411. Upon completion of Phases I, II, III and IV, all redundant program source code has been eliminated and only one copy of any unique set of instructions which is used more than once has become a "common library function" and has been stored in a new system library which is resident on disk. Calls to the functions in the system library have replaced redundant code in all interim source code files. In phase V the systems library is read into memory, step 501 , as shown in Figure 6 A. The number of programs which utilize common library functions are identified, step 502. Each instruction is compared to a common system function based on an Instruction Valuation File score, step 503. The score is assigned based on the instruction type. The scale is arbitrary with the more complex instructions having a higher score. A Temporary Library file is created and each instruction segment stored by name and velocity (score plus number of instructions per segment), in descending order by velocity, step 504. The Temporary Library File is stored in a Temporary Library File. A velocity report is printed listing each individual library code segment by name and velocity, in descending velocity order, step 505. As shown in Figure 6B, a user interactively selects the highest rated common functions based on the value of the velocity set forth in the velocity report, step 506. The instruction set for each of these most active common functions may then be manually optimized by the user, step 507. Thereafter, the system converts all of the interim source code from the pseudo to native code in which it originally existed, step 508. Optionally, the user may elect to compile the library to compiled library object code, step 509 on an affirmative election, the system converts the new source code instructions to call compiled library objects, step 510. In either case Phase V ends, step 511. Use of the optimized source code as provided by this invention is enhanced not only through the streamlining and optimization of code as described herein, but also due to the fact that the various library objects, once called, remain resident in memory and as such increased speed of operation of the programs is enjoyed due to called portions of the program being accessible at RAM memory speeds. DETAILED EXPLANATION OF PREFERRED EMBODIMENT Having thus described the overview of the invention as set forth above, Figures 8 A through 8Z illustrate by way of selective menus the operating sequence in more detail. Figure 8A shows the initial function screen presented to the user. The user is provided with three initial options. In Option (1), the user may select the Source Code Program analysis function. In Option (2), the user may select a review of current File and Element Definitions. In Option (3), the user may Convert, Scan or Repair Programs which have not previously been analyzed. On selection of Option ( 1 ), the user is presented with the screen set forth in Figure 8B and requested to enter Customer/ Application Data in the form of a number (this number is an arbitrary 4 digit number the first two digits representing a customer number and the last two representing the number of the specific group of applications source code to be processed for that customer) The user is also prompted to select whether or not to add search information to a Parsing Table. This could be information regarding a name, or part of a name, or any other data which the system is to present to the user for an examination of its attributes. For example, the user could request the system to find every data element which contains in whole or in part the letters "DATE" and to store the same in the Element Cross Reference File. This would permit the user to examine the date length of each such field and to permit change from a six byte field to an eight byte field, if necessary to accommodate the year 2000. Alternatively, the user may let the system seek out and examine every data element for inclusion in the Element Cross Reference File automatically as described above. On selection of the Parsing Table addition option, the user is prompted by the screen of Figure 8C to enter Parsing Arguments to be used during the scan process. In the example screen of Figure 8D, the data element in the parse table is the term DATE-. The resulting Element Cross Reference File will contain every data field with the term DATE- in its name. If left blank every data field will be placed in the Data Element Cross Reference File. In addition, the letter A indicates that an Auto-Correct Parsing Type for the date is to take place although the option to cause the system to Pause on Match is also available (Parsing Type "P"). If the system Pauses on match, the User may manually make the correction, in this case a length correction, or continue. In the case of Auto-Correct as is indicated in Figure 8D, the new length is mandatory and is automatically entered. In this case, the length is set to 08 characters, which accommodates the entry of years through the year 9999, which obviously, permits correction of the millennium problem of concern at the present time. The user is then prompted by screen of Figure 8E to enter either the name of a single program or a .BAT file or batch file containing the names of multiple related programs for processing by the system. On selection of the program or the programs, Phase I as described above commences and the user is continually advised of the status of the program by a status screen as shown in Figure 8F. The status screen, includes information which identifies the current program being processed and shows the historical data being collected by the system such as Programs Processed, Lines Processed, the number of Calls established and the number of lines called. Figure 8G shows the same processing screen at an intermediate stage of processing and identifies the various sections of the program being processed. Some of these include FILE- CONTROL, DATA DIVISION, FILE SECTION AND WORKING-STORAGE SECTION. In Figure 8H, the user is given the option to Enter Standard File Names. The help function under FI advises the user that Standard File Names are important because the source code allows logical referencing of any file by any name. Therefore, the same file may be accessed in different programs in the same group by different logical names. This step permits the correction of the name to a uniform name in a manner similar to that provided for in data element names which eliminates confusion where maintenance is required. On an affirmative selection the user is provided with a data entry screen 81 to select a new name. In the current example, the name CRM-DETAIL-AGINGB has been changed to BWS-DETAIL-INVENTORY. It may be that the logical file name CRM-DETAIL-AGINGB is actually an inventory file with inventory age information. The change helps avoid the misconception by maintenance programmers that it is related to accounts receivable. After selection of the logical file names, the system scans the source code files and restructures each instruction into a standard syntax and stores the restructured interim source code in virtual memory, (steps 201 and 202 of Figure 3.) Figure 8J illustrates the screen provided to the user on completion of the system analysis to prompt for the option to select Y or N as an option for printing the Element Where Used Report (step 108 of Figure 2B) after change of the various names and elements. On selection of the printing of the Element Where Used Report, the system prompts the user for a Change Element Definitions selection, Figure 8K. A help screen is provided defining Element Definitions for the user. These consist as noted above of Name, length, and Type and in the case of workspace allocations, Format. In this example, the user has been shown a data element "C A-DTL-PRINT- ASA" in the highlighted portion of the screen as shown in Figure 8L. This data element name was found in file CRM-DETAIL — AGINGC . The user is prompted to indicate whether change of the name is desired or not. In this example, N for no was selected. In Figure 8M, the screen shows that the name has been changed to CA-DTL-PRINT and the user is prompted for a length change of the same element. In this example, when the new name is entered, and the length is entered, the system then processes the changes and prompts the user for a print of the Where Used Report for the current Definitions, Figure 8N. This is confirmed by the screen shown in Figure 8N and the user is prompted again for a print of current definitions, i.e. an updated Where Used Report. Figure 80, prompts the user for a selection of printout of working storage definitions. This is essentially another Where Used Report of working storage allocations and definitions. These include an identification of all of the common work areas according to physical size and value (i.e., profile). The user may decide to change or redefine any data definition and/or change the value and physical size of a specific work area. The report permits the user to evaluate what changes are required. On an affirmative selection, a Working Storage Definitions report is printed. The user is then prompted to select whether a change in the working storage definitions is required, Figure 8P. On an affirmative selection, the user is given the option to select only Parsing Table matches (i.e., automatic changes on match) or by Program & Definition (manually step by step), Figure 8Q. On an affirmative selection, the system automatically selects storage definitions. The progress of changes is monitored in the screen of Figure 8R which shows a new Length, 0008, and a new Edit, in this case 9(08). (In COBOL PL 1 the 9 is a field type code, i.e., "numeric" for a numeric field length of 08 bytes. The system automatically changes all definitions which occupy the same physical location. If the user selects the negative, the system will provide a prompt for each definition where the user enters Program and Definition information which requires the user to enter the change information during the run. Figure 8S illustrates the user screen with new length information entered and new edit information awaiting entry. On completion of all Phase II changes, the user is prompted for additional options as shown in Figure 8T. These are : 1. REPLACE Source Code Definitions with NEW STANDARD 2. REPAIR Source For Occurrence of SPECIFIC ELEMENTS 3. CREATE AIM Specifications from SOURCE CODE 4. COST ANALYSIS of Source Code/System CORRECTION The user may escape to the main menu Figure 8 A or continue with one of the above options of Figure 8T. At this point in the example, The source code has been processed through Phase I and Phase II. On selection of Option 1, the system enters Phase III and the user is prompted by the screen in Figure 8U as to whether or not common functions are to be identified. The user is then presented with the screen of Figure 8V to display the standardization default parameter used to calculate the benefit derived from the Optimization process. The screen of 8V allows the user to modify the default assumptions, before computation of the benefit. On an affirmative selection, the user is presented with the screen of Figure 8W to indicate which programs are to be repaired and Phase III, Phase IV and Phase V are completed. The user is presented a status screen as shown in Figure 8X which shows the system adding the common functions as described in the overview above. Figure 8Y displays to the user that the common function building process is completed and provides the user an option to print the completed library. The user is advised by the screen of Figure 8Z that the system is creating the function library. That is, saving all common functions to the system library. Other options are available as indicated in Figure 8A these include a Review of Current File and Element Definitions (Option 2) which is essentially a printout of the various Where Used Report information as shown in Figure 19. In addition, in Option 3, a Convert, Scan or Repair Programs Analyzed Option is available. That is without entering the Analyzer process (Phase 1 through V) described above the user may directly access the program code in any of the program files and perform certain changes. Selection of this option places the user at the screen of Figure 8T. With reference to Figure 9A, the user may initiate a Repair Option, step 600 by selecting Option 3 of the screen of Figure 8 A and commencing the Repair Function as shown in Figure 9A. The user enters the file name or .BAT file containing all of the program files which are to be repaired, step 601, and the system commences reading the interim source code files, steps 60-604. Referring to Figure 9B, the system reads the source code files and determines the logical file name used to access each file and creates a File Name Cross Reference File of logical names and related physical file names, step 602. The File Name Cross Reference File is stored on disk, step 602. Each instruction in each source code file or module is again read from the interim source code files and its type determined. Those instructions which operate on a data element are analyzed and the data element identified. The name and other attributes of the data element are determined and an Element Cross Reference File containing each data element by name and its associated attributes is created , step 603. The Element Cross Reference File is stored on disk as in automatic processing: Each instruction in each source code file or module is again read from the interim source code file and its type determined. Those instructions, which define work space allocations are analyzed and the work space identified. The workspace is analyzed by structure and a Work Space Common Occurrence File for workspace definitions is created, step 110. The Work Space Common Occurrence File contains the same information as in automatic processing. The system provides for interactive communication with a user, who may indicate that a Where Used Report is or is not to be generated. With reference to Figure 9B, a File Where Used Report for logical file names, may be selected for display or print by the user. A File Where Used Report is a report of the contents of the File Name Cross Reference File with information sorted by physical location. This permits the user to evaluate which of the various logical file name references refer to the same physical file. If the user indicates that such a report is required, step 610, the system prints out a report, step 611. The user may then examine the report and define new logical names for selected physical files. On review of the File Name Where Used Report the user may enter search information in a Parse Table, Figure 9C. If such information is entered, step 612, the system searches for files matching the Parse Table, step 613. The system does not search for files by name for those files which are not selected by the Parse Table. If the user defines a new logical name, step 614, the new name is substituted for the first occurrence of each unique file in the File Name Cross Reference File, step 615. Uniqueness is determined by the actual name of the file referred to by the logical file name. Multiple unique logical file names may be selected by the user for change and the user is given the opportunity to change the next physical file name step 616. On processing the last file name, the system goes to the next stage, step 616. An Element Where Used Report, Figure 9D, may be selected for print by the user, step 617. An Element Where Used Report is a report of the contents of the Element Cross Reference File with information sorted by physical location. This permits the user to evaluate which of the various data elements are stored in the same physical location. If the user indicates that such a report is required, the system prints out a report, step 618. The user may then examine the report and define new attributes for selected variables. On review of the Element Where Used Report the user may enter search information in Parse Table, step 619, as shown in Figure 9E. If such information is entered, the system searches the Element Cross Reference File for the data elements which match the Parse Table, step 122. The system does not search for any data elements for which no selection was made by the user. These element definitions may be a change by the name, type or length or any other attribute of the data element. In the case of a six byte date, for example, the user may wish to change the length to eight bytes in order to accommodate a four byte year such as the year 2000. If the user defines a new name or new attributes, step 621, the new data is substituted for the first occurrence of each unique data element in the Element Cross Reference File, step 622. Uniqueness is determined by the physical location of the data element in the virtual memory. Multiple unique data elements may be selected by the user for change and the user is given the opportunity to change the next element name or attributes, step 623. On processing the last file name, the system goes to the next stage, step 623. As shown in Figure 9F, a Work Space Where Used Report for work space information, may be selected for display or print by the user, step 624. A Work Space Where Used Report is a report of the contents of the Work Space Common Occurrence File with information sorted by physical location. This permits the user to evaluate which of the various work space allocation parameters require change. For example, if a data element size is changed, the corresponding size of a work space may also require change. If the user indicates that such a report is required, step 624, the system prints out a report, step 625. The user may then examine the report and define new attributes for selected workspace parameters. Onreview ofthe Work space Where Used Report the user may enter search information in a Parse Table, step 626, as shown in Figure 9G. If such information is entered, the system searches the Work Space Common Occurrence file for common work spaces which match the Parse Table, step 627. The system does not search for any other Common workspace definitions for any workspace allocations for which no selection was made by the user. The essential difference between searches is that work space is searched by its profile file by names and elements by name or attribute. These new definitions may be a change in the format, type or length or any other attribute of the workspace parameters. If the user defines a new name or new attributes, step 627, the new data is substituted for the first occurrence of each unique work space in the Work Space Common Occurrence File, step 628. Uniqueness is determined by the form of the workspace allocation. Multiple unique workspace definitions may be selected by the user for change and the user is given the opportunity to change the next work space definition, step 629. On processing the last work space definition, the system goes to the next stage, step 629. Referring to Figure 9H, if the user changed a File Name, step 630, the interim source code is checked and each logical file name is compared with the File Name Cross Reference File. Each reference to the same physical file name is changed to the logical name of the first occurrence of the logical file name associated with the same physical file as set forth in the File Name Cross Reference File, step 631 , as determined by the system or selected by the user. If a data element was changed, step 632, the interim source code is again checked and each data element name is compared with the Element Cross Reference File. Each reference to the same element in the same physical location is changed to reference the name and attributes of the first occurrence of the data element as set forth in the Element Cross Reference File, step 633 as determined by the system or selected by the user as shown in Figure 91. If work space was changed, step 634, the interim source code is again checked and each work space allocation is compared with the Work Space Occurrence File. Each reference to the same work space in the same format is changed to reference the parameters of the first occurrence of the work space definitions as set forth in the Work Space Occurrence File, step 635 as determined by the system or selected by the user, Figure 9J. However, the user cannot select a new workspace name . The system creates a new reference name for each unique Work Area, step 636, in the following format: WS- ooo-cccc-llll-sss, where "ooo" is the occurrence number, i.e., the first occurrence of the same work space allocation (ooo=001 and so on), "cccc" is a four digit number representing the size of the work space in characters, "1111" is a four digit number representing the number of lines of work area, and "sss" is a three digit number representing the sequence of lines of workspace allocated. That is, the order of identical work space allocations defined in sequence. The information required regarding the format of the Work Area is derived from the Work Space Common Occurrence file which defines each such area. The maximum sequence number is an indication of the largest number of work space allocations in any program sequence. Certain programs may overlap in all or part of the Work Area allocations. This means that if program 1 uses work space allocated in sequence 001 through 006, and program 2 uses workspace allocated in sequence 001 through 003, each program will utilize the same physical space in sequence 001 through 003. Program 1 of course uses additional space 004 through 006. Since the programs run at different times this use of the same work area does not create any conflict, but simplifies the code with standard definitions with equivalent work space used by different programs. The name created is substituted for each reference allocating the work area in sequence within each program step 138. This means that each work space name has the attributes of the work space built into the name and makes future maintenance less confusing. The user is provided an option to reprint the File Name Where Used Report for the revised file names, step 637, Figure 9K. On an affirmative selection, the revised File Name Where Used Report is printed, step 638, as shown in Figure 2L. In Figure 2L, the user is then provided an option to reprint the Element Where Used Report for the revised data element names and attributes, step 639. On an affirmative selection, the revised Element Where Used Report is printed, step 640. The user is also provided an option to reprint the Work Space Common Occurrence Report for the revised workspace allocations, step 641. On an affirmative selection, the revised Work Space Common Occurrence Report is printed, step 642, and Phase I ends, step 643. Figure 10A illustrates the screen presented to the user when the Repair Option is selected in Option 3 and the user is prompted to enter the program name for conversion. As in the Analyzer, either a name or a .BAT file of names may be entered. The program ensures that the printer is on-line so that the various Where Used Reports may be generated, Figure 10B, and the system commences scanning the programs. A parse table, parses out the various file name and data elements selected by the user and to be individually changed by the user. The process is essentially the same as the Analyzer section but only selects for change those items entered by the user. The user is presented with a screen requesting the name of the program or the .BAT file of the programs to be repaired. The parse table may include a date definition because all the users wishes to do is expand the date field length. Screen 10B ensures that the printer is on line so that an audit trail of corrections may be printed. Figure IOC shows the user that the system is scanning the various files for the parse table elements. In this particular example, the name of the element is MY DESCRIPTION and it is any character of length (30). Figure 11, illustrates the AIM conversion routine, step 700. The Conversion creates new edit words, step 701, a validation table, step 702, new data base files, step 703, new data screens, step 704 and report forms, step 705 and the conversion ends. The screen of Figure 12A demonstrates the conversion to the automated information management system specifications for a codeless environment. On completion of such conversion, Figure 12B advises the user of the number of edit words used, validation tables required, data bases created, screens created and reports created. Figure 13, illustrates the cost analysis option. The cost analysis option is initiated on selection by the user, step 800. The cost analysis option displays financial assumptions to the user for evaluation, step 801 and prompts the user for changes, step 802. The cost analysis option then displays six cost basis for examination, step 804, and the user may select all or any part thereof for analysis, step 804. The system then computes the various cost elements and displays the cost estimates for a variety of repair options, step 805. The screen of Figure 14A presents the assumptions used on selection of the Cost Analysis option. The screen of Figure 14B permits the user to elect which element of cost should be included in the cost analysis for examination. The user may select all or none of the six cost basis parameters. Figure 14C is a screen which illustrates for the user the total cost for the parameters selected for four repair/conversion techniques. These are Manual Find and Fix options of the instant invention, COBOL reprogramming, or reprogramming in another 4th generation language, and using the instant invention. In this case, one (1) program was analyzed, and (2322) lines of code evaluated. Figure 15 A and B, show the data base structure for I/O elements and common I/O file structure used in the intervention. Most of these definitions will be readily apparent to those skilled in the art. However, a few of these data base elements will be described in more detail. For Figure 15 A the Data Base number is the sequential number of 'E' records. The element edit is the format of element for display. Parse Type is A(automatic) or P(pause) parseid is the position of a record in the Parse Table. For Figure 15B a system assignment is the physical location on disk where the file is stored. (The record name is the level 01, 05, 10, etc. Record size is in characters. The table type is either standard definition or omitted). The assigned data base number is the sequential number of 'D' records. For Figure 16A, Wl contains a record for every level of instruction. Value, if any, is a sub-profile picture and any default values. For Figure 16B, W2 is a summary record using Wl . Occurrence is the number of occurrences of the code in a program. Sequential number is always 001 and is used to compare to 01 level. Sub level is the top level of the work area, i.e., 77, 01, etc. For Figure 16C and 16D the names of the fields illustrate the nature of the stored contents. For Figure 17A through 17D, the names are descriptive of the contents. The term (Function Number) indicates a sequential number assigned to the common function. The (Sequential Number) is the number indicating the order of the instruction found in the block. For Figure 18, the term partial parse word is the sub-string to be searched in a string. Figure 19 is a flow chart of the REPORT OPTION of Option 2 of Figure 8A. Further advantages and uses for this invention will be recognized by those skilled in the arts. The instant invention is contemplated to embrace such other uses and features and is not intended to be limited strictly to the preferred embodiment disclosed. Having thus described the invention what is claimed is:

Claims: CLAIMS 1. A computer optimization system recorded on a computer readable medium for optimizing computer software comprising: a. a conversion routine which reads the source code stored in at least one source code file stored on said computer readable medium and writes said source code into an intermediate source code file on said computer readable medium; b. a vertical synchronization system for processing said intermediate source code file and constructing a data structure related to the source code in said intermediate source code file; c. a horizontal synchronization system for scanning the source code of said intermediate source code file and converting the source code into an intermediate source code having a standard syntax; d. a sequential synchronization system for scanning said and determining if any intermediate source code segments are common to other said intermediate source code segments; e. an intermediate source code modification system for scanning all of said intermediate source code and replacing common code with a library reference for accessing said code from a library; and f. a restoring system which writes the revised intermediate source code to the source code file on said computer readable medium. 2. An optimization system as described in claim 1 wherein said vertical synchronization system comprises: a. a cross reference routine which analyzes said intermediate source code file and creates a data base structure for a plurality of references to elements used in any of the said intermediate source code, which data structure comprises at least the element name, length, and location, and identifies specific intermediate source code instructions that references reference each such element; b. a scan routine which scans all of the intermediate source code and changes the attributes of elements referenced to a selected attribute; and c. a standardization routine which assigns at least one common attribute to each referenced element at a common location. 3. An optimization system as described in claim 2 wherein said element attribute may be selected interactively by an operator of the system based on an output display from said system. 4. An optimization system as described in claim 3 wherein said display is a printed report. 5. An optimization system as described in claim 3 wherein said display is a formatted screen display generated by said system. 6. An optimization system as described in claim 2 wherein said horizontal synchronization system comprises: a. a syntax scan routine which scans the intermediate source code file and changes all instructions of said intermediate source code to a particular syntax. 7. An optimization system as described in claim 1 wherein said sequential synchronization system comprises: a. a library scan routine which scans all of the intermediate source code and selects segments of such code for a library common function file and stores such segments in said library common function file. 8. An optimization system as described in claim 7 wherein said sequential synchronization system further comprises: a. a replacement routine which removes each segment stored in said library common function file from the intermediate source code; and b. substitutes a call instruction to the code segment stored in said library common function file, in each location from which said segments have been removed. 9. An optimization system as described in claim 1 wherein said intermediate source code modification system further comprises: a. a read routine which reads all of the intermediate source code in the intermediate program source code file and removes all common said intermediate source code segments from the intermediate source code file and inserts calls to the library common function file to use the segments designated by the call which are stored in the library common function file. 10. A computer program product comprising: a. a computer usable medium having computer readable program code embodied in said medium for causing optimization of source code; and wherein said computer readable program code further comprises:: i a conversion routine which causes said computer to read at least one source code file stored on said computer readable medium and converts the source code in said source code file into an intermediate source code ; ii. a vertical synchronization system which causes said computer to process said intermediate source code and to construct a data element data structure related to each instruction in said intermediate source code which uses said data element; iii. a horizontal synchronization system which causes said computer to scan each instruction of said intermediate source code, to convert each named data element in said intermediate source code to a standard data element name and to convert each instruction in said intermediate source code into a standard syntax; iv. a sequential synchronization system which causes said computer to scan all of said intermediate program source code and to evaluate if any code segments are common to other code segments of said intermediate program source code; v. an intermediate source code modification system which causes said computer to scan all of said intermediate program source code and to replace common code segments with a library reference for accessing said code segments from a library; and vi. a restoring system which causes said computer to store the modified intermediate source code to the source code file. 11. An optimization system as described in claim 10 wherein said vertical synchronization system comprises: a. a cross reference routine which analyzes said intermediate source code file and creates a data base structure for every individual data element used in any instruction of the intermediate source code, which data structure comprises at least the element name, length, and location, and identifies each program instruction that references each such location; and b. a standardization routine which assigns a single selected name for each data element at a common location. 12. An optimization system as described in claim 11 wherein said element name may be selected interactively by an operator of the system. 13. An optimization system as described in claim 11 wherein said horizontal synchronization system comprises: a. a name scan routine which scans all of the intermediate source code and changes all data element name references to the selected name; b. a syntax scan routine which scans the intermediate source code and changes all instructions to a standard syntax. 14. An optimization system as described in claim 10 wherein said sequential synchronization system comprises: a. a library scan routine which scans all of the intermediate source code and selects segments of such code for common library functions and stores such segments in said library common function file. 15. An optimization system as described in claim 10 wherein said intermediate source code modification system comprises: a. a read routine which reads all of the program instructions and removes all common instructions from the source code and inserts calls to the library common function file to use the segments designed by the call which are stored in the library common function file.

Inventors: PRICE THOMAS J, PRICE, THOMAS, J.
Applicants: PRICE THOMAS J, VERONEX TECHNOLOGIES INC, PRICE, THOMAS, J., VERONEX TECHNOLOGIES, INC.
Application year: 1998
Main classification: G06F9
IPC codes: G06F9