Software redevelopment system5812849Abstract A predetermined change to a software system having a large number of highly connected and interrelated executables and data files is accomplished using a redevelopment database which is generated from a software library. The redevelopment database maintain resource and relational information on the executables and data files. This information is used by a partitioner which creates groups of executables and data files which have minimal connections to executables and data files outside a given group. The groups are assigned to a resource, with the resource performing the software changes in a given group with the aid of software change mechanisms. After the changes in a group are completed, a configuration management system of the software system receives the newly modified software, updating the software system. The configuration management system also notifies the redevelopment database so that the relational and resource information of the redevelopment database remains up to date, and continues to support the day-to-day modifications other than the predetermined software change. Claims We claim: Description BACKGROUND OF THE INVENTION
______________________________________
Score =
C * (# of connections in a partition) +
P* ( (# of connections in a partition) / (# of connections))
(2)
______________________________________
two components. The first component weighs the importance of the number of connections that the object has in a partition, and the second component normalizes the score with the fraction of the number of connections in a partition in relation to the objects total number of connections of the object. In the event that there are multiple programs or files with the highest Score, the program or file with the greatest number of connections is selected as the kernel object. In addition, if no partitions have been created, all programs and files will have a score of zero, therefore the program or file with the greatest number of connections will be used as the kernel. Once the kernel object has been chosen, the score for all objects, which are connected to the kernel object (i.e. having a reference to or from the kernel object) are re-Scored 320 using equation (2). The user specified number of objects with the highest score are then added to the current partition being generated 322, and the Score for each object connected to an added object is recalculated using equation (2) 324. After this is accomplished, a user specified number of objects are deleted from the partition 326. The objects deleted are those with the lowest score. The objects connected to the deleted objects are then re-scored using equation (2) 328, and the deleted objects are then returned to the general pool 330. After this has been accomplished, the partition size is measured to determine if the minimum size for a partition has been reached 332. If the minimum size has not been reached, the first stage process is repeated, starting with the addition of the specified number of objects with the highest score 322. If the minimum partition size has been reached, stage two is initiated 334. Referring to FIG. 14, the second stage of the partitioning entails growing the partition of the first stage until a maximum partition size is reached. This is done by attempting to add all objects having a percentage of their connections in a stage 1 partition or a certain fraction threshold of their connections to the stage 1 generated partition 336, as it is referred (set by the user selection of Min Pct Internals to Add from Pool 298 of FIG. 11). If this results in a partition which is greater than or equal to the maximum desired size of a partition 338 (set by Maximum Size 282 of FIG. 11), the second stage is complete 342. If the maximum size of the partition is not reached, and all objects with a certain fraction threshold of their connections are included in the first stage partition, objects that have at least a certain lower minimum percentage threshold of their connections in partitions are added to the partition under development if connected to an object that has at least a certain higher minimum percentage of their connections in a partition already created 340. (Note that the certain lower minimum percentage is specified by the user in Min Pct Internals from Pool 300, and the certain higher minimum percentage is specified by Connected to Min Pct Internals in Partition 302, both of FIG. 11) Once this has been accomplished, the second stage is complete 342. Referring to FIG. 12, after the second stage is complete, the determination is made as to whether the user selected number of partitions has been generated with the addition of the partition created during the current iteration 344. If the correct number of partitions has been generated, the partitioning is complete, and the application ends 208. If more partitions are required, stage 1 is re-initiated, beginning with the addition of a user specified number of objects to the new partition being generated 310. FIG. 15 presents the logical design for implementing the partitioner application. The design is centered around a double linked 348 list of objects that are to be partitioned 350. The list objects 350 is ordered based upon the score of the objects, as calculated using equation (2). The higher the score, the closer an object is to the start position (352, 354) of the partition 356 and pool 358. Furthermore, by maintaining the start position (354) of the pool 358 and end position of the partition 356, the boundary 360 between the partition 356 and pool 358 is created. An array of connections 362 is defined for each object. Each object has an array of pointers to all other objects that are referenced by the object. In this way, as an object is added or deleted from the partition, the array of connections 362 can be used to directly update the scores of the connected objects. Furthermore, an object with an updated score can be easily moved up or down the collection through the use of the double linked list, with most objects moved in small incremental steps, thereby minimizing the cost of a linear search in order to reorder the object in the double linked list. The following partition object data type was defined in Visual Basic 3.0.
______________________________________
Type Partition Object
Next As Long
Previous As Long
Total As Integer
Internal As Integer
ScoreFactor As Integer
Score As Long
Partition As Integer
Connection As Long
End Type
______________________________________
This allows an array of partitions to be created, with indexes in the Partition Object array used as pointers. The "Next" and "Previous" fields are pointers that provide the double linked list capability. "Total" is the total number of connections of an object, with the number of connections that an object has contained in a partition, specified by "Internal." The "ScoreFactor" based on the user provided parameters is maintained, along with the current "Score" of the object. The current partition to which an object is assigned is stored, and "Connection" provides an index into the Connection array that points to the set of references of an object. A limitation of Visual Basic 3.0 is that a single dimension in an array limited to 32K. This limitation places the requirement to have a multi-dimensional array when a data object, having a 32K size, may exist. The partition objects array of the preferred embodiment supports nearly 100,000 Partition objects. In addition, a subroutine can be defined (`pntrListConvert`) that converts the `long` index into two `integer` indexes for the two dimension array using integer division and modulus functions. The declaration used are as follows:
______________________________________
ReDim PartitionObjectsArray(0 to 2, 0 to 32766) as
PartitionObject
Global ConnectionsArray(0 to 9, 0 to 30000) as Long
Sub pntrListConvert (anID As Long, anID1 As Integer, AnID2 as
Integer)
______________________________________
For illustrative purposes, Appendix 3 presents an example of how an object (referred in the source code as an element) is moved through an array using the "Next" and "Previous" pointers. Movement forward in the List is based on the score of the object. The higher the score, the closer to the front of the list an object will be located. The "Previous" pointers of the objects in the list are used to find the correct position for the given object. Once found, the affected object pointers are updated. Conversion to the two dimension array is also shown in the illustrative example of appendix 3. Once the partition boundary or work units have been calculated, the responsibility for each cluster or work unit is assigned to a responsible group. This was accomplished by importing the partitioner output, including associated resource information into an Access Database program. Using the database, partitions were assigned to a particular information system group or person. This assignment was based upon the number of programs and data files "owned" by a person or group in a partition. The group with ownership of the majority of data files and executables within a work unit was given the task to change the cluster. It should be noted that this assignment can be based upon a wide variety of resource information. Once the partitioning and assignments are completed, the elements contained within the partitioned clusters are changed by the responsible group. As shown in FIG. 16, changing the elements 96 consists of modifying the code 210, unit testing 212, and partition subsystem testing 214. In order to assist individuals in modifying the code 210, a data name finder was utilized to identify the locations of the elements requiring a change. FIG. 17 illustrate a system overview of the data name finder. The data name finder 370 uses the program source code 372 contained in the DCCS 374 as an input. This tool is used with an editor 376 to search a program for variable names contained n the synonym list 378 generated by the synonym finder, or variables which receive a variable name, collated in the internal synonym during data name finder execution. FIG. 18 shows the functional flow of the data name finder. Initially, all lines of the source code are marked as "undisplayed 382." In conjunction with an editor, each program line is searched for variable names contained in the synonym list and internal synonym list 384. When a line that contains a match to synonym finder item is located, the line is marked as "displayed" 386. Furthermore, each line is searched for a variable reassignment 388. If a line reassigns a found data name to another variable, the other variable is added to an internal synonym list 390. In this way, internal working variables of an element are also identified as potentially requiring change. For example, if part number in a program uses the content of a variable WORKING-STORAGE-MISC, lines with this variable will be marked as "displayed" so that an individual performing the changes to a program will investigate the potential need to change this variable due to the part number change. The process is repeated until each line of code is checked 392, Ultimately an output which lists all variables are marked as "displayed" and their location (i.e. line numbers) in the program is produced (see FIG. 17, data name finder output 394). Individuals were also assisted with code modifications with the truncation detector. FIG. 19 provides a system overview of the truncation detector. The truncation detector 400 uses compiler output 402 as an input. It also utilizes the synonym list 404 to identify the variables which were to have been changed, and as with the Data Name Finder, it also uses an internal synonym list 406 which identifies variables not in the synonym list 404. The truncation detector 400 verifies the format of each variable against a specified format (which in the case is that the part number field should be at least 10 characters in length) and generates an output error file 408 containing variables that do not meet the format criteria prior to compilation of a program. FIG. 20 shows the functional flow for the truncation detector. The first step consists of selecting a synonym from the synonym list, or if that list has been exhausted, the internal synonym list 410. The compiler output is then searched for the selected synonym 412, and if the variable is present, a check is made to see if the synonym variables contents are moved to a new variable 414. If this is found, the new variable is added to the internal synonym list 416. The format of the originally selected synonym is then verified to ensure the length is greater than or equal to the size required by the change 418. If the size is not greater than or equal to the size required by the change, the synonym variable is written to the error file 420. If all the synonyms in the synonym list and internal synonym list have been verified, the truncation detector ceases execution 422, otherwise, the above described process is repeated, starting with the selection of a synonym in the synonym list or internal synonym list 410. The last tool used to assist in the changing the code, is the IMS bridge. The IMS Bridge facilitates the conversion of computer programs which access the hierarchical database IMS DL/I database (an IBM product). Specifically, the part number field of converted computer programs have a larger data size (i.e., ten positions for a part number datum) than what the IMS database had for its part number field (i.e., eight positions for a part number datum), the IMS Bridge is used to allow modification of the program without changing the IMS DL/I database. FIG. 21 provides an example of one operational sequence of the IMS Bridge. The calls from a computer program 430 to an IMS database 434 are intercepted. The intercepting routine at function 438 compresses the Part Number field(s) to eight positions and passes to the IMS database 434 the current segment size on a Replace or Insert. The IMS Bridge expands at function 442 the Part Number field(s) and segment size, when the computer program 430 is accessing data from the IMS database 434. FIG. 22 depicts the interrelationship between the IMS Bridge and its environment. A computer program 430 uses a datum 460 (e.g., a part number field) with a first size 464, such as ten positions. A data store 468 (e.g., a hierarchical IMS database 70) uses the datum 460 but with a second size 472, such as eight positions. A datum transfer direction determinator 476 determines the direction by which the data will be exchanged. The direction indicates whether a datum is being transferred to the computer program 430 or to the data store 468. A database operation determinator 480 is used to examine the database operation being used to effect the exchange of data between the computer program 430 and the data store 468. A list 484 provides an example of the type of database operation which the database operation determinator 480 can use to determine the direction of the exchange. For example a retrieval database operation indicates that the direction for the exchange of data is from the data store 468 to the computer program 430. The data size adjuster 488 adjusts the size of the datum 460 which is being exchanged between the computer program 430 and the data store 468 so that a datum 460 with an adjusted size 489 is produced. The adjustment of the size of the datum is based upon the determined datum transfer direction and upon a predetermined data size adjustment value 492. The data size adjustment value 492 indicates how much the data size should be expanded or compressed. For example, the data size adjustment value 492 would be two if the computer program 430 has size of the datum at ten and the data store 468 has the size of the datum at eight. Therefore, a compression of a datum from ten places to eight places deletes the last two positions (i.e., ending positions) of a predetermined number of the datum, and an expansion of a datum from eight places to ten places involves "padding" the datum with two blank spaces (each of EBCDIC value of 40 decimal) at the end of the datum. The data size adjuster 488 is disposed between the computer program 430 and the data store 468 so that the datum is effectively intercepted before the datum has been received by the data store 468 or is effectively intercepted before the computer program 430 receives the requested datum depending upon the datum transfer direction. An internal segment table 496 and an internal key table 500 store the data size adjustment value 492 for each particular datum type. The structure of the internal segment table 496 and the internal key table 500 is discussed in greater detail below. Within the IMS environment, the IMS Bridge uses four called computer routines beginning with `CBLTCONV`. The `CBLTCONV` routine replaces the `CBLTDLI` routine. The `CBLTDLI` routine has the function of performing database operations against an IMS database from a COBOL or assembler program. The `CBLTCONV` routine has the function of performing the same database operations as the CBLTDLI routine while expanding/compressing I/O areas and compressing SSAs when found in internal tables. The IMS Bridge allows the computer program conversion and expansion of Part Number fields independent to the database conversion. Any IMS on-line or batch program that converts its I/O area to accept expanded Part Number field(s), has the normal call to IMS changed from `CBLTDLI` to `CBLTCONV`, whenever it is attempting to Get, Replace, Insert to, or Delete data from the `converted` database. The I/O area refers to the segment(s) or records retrieved or to be inserted or updated from/to an IMS database. The parms passed to `CBLTDLI` are the same parms currently passed to `CBLTDLI`. The term "parms" refers to any items following a call (i.e. database operation, db pcb, I/O area, and SSAs). The call to `CBLTCONV` could be dynamic. Program `CBLTCONV` is an assembler program that counts the number of parms passed from the computer program. It also calls a Cobol program `CONVCBL` dynamically. Program `CONVCBL` is a Cobol program that makes the call to IMS using `CBLTDLI` before or after the I/O area and SSAs passed have been expanded or compressed. The term "SSA" refers to the keys or indexes passed to the IMS database to retrieve or update segment(s). Program `CONVCBL` calls `CONVSIZE`. Program `CONVSIZE` is an assembler program that expands or compresses the I/O areas and SSAs passed to it. Therefore, the IMS Bridge consists of 4 called programs: CBLTCONV (Assembler-called statically or dynamically) CONVCBL (Cobol-called dynamically) CBLTDLI (Standard IMS call, static) CONVSIZE (Assembler-called dynamically) Within the IMS environment, Cobol programs which access IMS databases use a "call" routine "CBLTDLI" supplied by IBM. This call routine requires information to be passed from the program to IMS to complete the desired database operation. An example of a Call routine is as follows:
______________________________________
CALL `CBLTDLI`
using `GU`, retrieval database operation
db-pcb, database information
I/O area, result of database retrieval
(segment)
SSA key or index used to retrieve data
______________________________________
The above "call" is replaced with:
______________________________________
CALL `CBLTCONV`
using `GU`, retrieval database operation
db-pcb, database information
I/O area, result of database retrieval
(segment)
SSA key or index used to retrieve data
______________________________________
The `GU` term above refers to `get unique`, which indicates to the IMS to get a specific segment(s). The term `db-pcb` above refers to the application view of the database structure. Referring to FIG. 23, the start block 550 indicates that the first block to be processed is block 554. At block 554, the number of items being passed from the application program are calculated. In other words, a CBLTDLI call typically requires a minimum of three pieces of information (db operation, db-pcb, I/O area) and up to fifteen SSAs. Depending on the database operation and the number of SSAs passed, there may be more than one segment in the I/O area. If Decision block 558 determines that SSAs exist, then processing continues at continuation block C 562. The existence of SSAs refers to the possibility that the key needs to be compressed. If Decision block 558 determines that SSAs do not exist, then processing continues at decision block 566. If decision block 566 determines that the database operation is an insert, replace or delete operation, then block 572 is performed. Block 572 performs compression of the I/O area and then the CBLTDLI routine is called at block 573 before terminating at end block 750. If decision block 566 determines that the database operation is not an insert, replace or delete operation, then decision block 576 is performed. If decision block 576 determines that the database operation is a retrieval, then the CBLTDLI routine is called at block 577 and the I/O are is expanded at block 580 before terminating at end block 750. If decision block 576 determines that the database operation is not a retrieval, then processing terminates at end block 750. Referring to FIG. 24, continuation block C 562 indicates that block 600 is to be processed wherein the SSAs are parsed. At block 604, the SSAs are matched to the internal table to see if a match was found in the table. If decision block 608 finds a match, then the I/O area is compressed at block 612, else decision block 616 is immediately processed. If Decision block 616 determines that there are more SSAs, then processing continues at block 600. If Decision block 616 determines that there are no more SSAs, then processing continues at decision block 617. For each match found in the internal table as determined at decision block 617, processing continues at decision block 620; else processing continues at block 629 wherein the CBLTDLI routine is called before terminating at end block 750. If decision block 620 determines that the database operation is an insert, replace or delete, then processing continues at continuation block A 624. If decision block 620 determines that the database operation is not an insert, replace or delete, then processing continues at decision block 628. If decision block 628 determines that the database operation is a retrieval, then processing continues at continuation block B 632. If decision block 628 determines that the database operation is not a retrieval, then processing continues at block 629. Referring to FIG. 25, continuation block A 624 indicates that block 691 is to be processed wherein the internal segment table is searched. If a match is found at decision block 693, then the I/O area is compressed at block 700 and decision block 704 is processed next. If a match is not found at decision block 693, then decision block 704 is processed. If decision block 704 determines that there are more segments, then processing continues at block 691, else processing continues at block 705. Block 705 calls the CBLTDLI routine and then processing is terminated at end block 750. Referring to FIG. 26, continuation block B 632 indicates that block 711 is to be processed wherein the CBLTDLI routine is called. Next, block 713 searches the internal segment table. If a match is found at decision block 715, then the I/O area is expanded at block 720 and decision block 724 is processed next. If a match is not found at decision block 715, then decision block 724 is processed. If decision block 724 determines that there are more segments, then processing continues at block 713, else processing terminates at end block 750. The following processing is performed for compressing the I/O area from the computer program: using information from a prior retrieval operation, internal segment table and the SSAs passed, determine the size of the I/O area, the positions and lengths of the segment to be compressed; calls are then made to an assembler routine CONVSIZE to do the actual compression; a call is made for each segment in the I/O area. If the I/O area has more than one segment, the size of the I/O area as well as positions in the segment to be compressed are adjusted after each call to CONVSIZE. After the SSA's and the I/O area are compressed, the normal CBLTDLI call is made. Control is returned to the application program (IMS returns a status). The following processing is performed for expanding the I/O area from the computer: after SSAs are compressed, the normal CBLTDLI call are used to fill the I/O area; if the call was successful, the information from the internal segment table is used and the SSAs are passed, then the size of the I/O area is determined as well as the positions and lengths of the segments to be expanded. Calls are then made to an assembler routine CONVSIZE to do the actual expansion. The number of calls depends on the number of segments returned from IMS. The expanded I/O area is passed to the application program. If the call was unsuccessful, return control to the application program, as well as IMS return status. The following processing is performed to parse the SSAs as issued from the computer program: determine if the SSA has a valid, type, length or boolean operation present. The following processing is performed for compressing the SSAs: Determine where in key, field is to be compressed; a call is made to assembler routine CONVSIZE to compress SSAs. Internal Segment Table The internal segment table is used to expand or compress the I/O area passed to program CONVCBL depending on the function call passed. It contains the database name, segment name, segment size, the ending position of the part number and the size to expand or compress. Currently the table allows for 25 occurrences of part numbers per segment. Since some calls to IMS may include path calls it is necessary to enter all the segments within a database and their size though the segment may not contain a part number. The program allows for five rows for the same segments. In other words 5.times.5 or 25 occurrences. The table below reflects five rows allowing 25 positions for expansion or compression. An example of an internal segment table is as follows:
______________________________________
01 DBD-SEGMENT-TABLE.
05 DBD-SEG-TABLE.
10 FILLER PIC X (45) VALUE
`OCPTSDBDSFPARTRT02800008200882011620000000000`.
123456789012345678901234567890123456789012345
1 2 3 4
05 FILLER REDEFINES DBD-SEG-TABLE.
10 DBD-SEG-TBL OCCURS 20 TIMES.
INDEXED BY DBD-SEG-INDX.
15 DST-DBD-SEG-NAME
PIC X(16)
15 DST-SEG-SIZE PIC 9(4)
15 DST-SEGMENT-PART
OCCURS 5 TIMES
INDEXED BY DBD-SEG-PART-INDX.
20 DST-PART-END-POS
PIC 9(4).
20 DST-CHNG-LENGTH
PIC 9.
______________________________________
In the above example:
______________________________________
Positions 1
8: Database Name: OCPTSDBD
Positions 9
16: Segment Name: SFPARTRT
Positions 17
20: Segment Size: 0280
Positions 21
24: 1st PartNo ending position:
0088
Positions 25
25: 1st PartNo change length 2
Positions 26
29: 2nd PartNo ending position: 0116
Positions 30
30: 2nd PartNo change length 2
Positions 31
34: 3rd PartNo ending position:
0000
Positions 35
35: 3rd PartNo change length 0
Positions 36
39: 4th PartNo ending position:
0000
Positions 40
40: 4th PartNo change length 0
Positions 41
44: 5th PartNo ending position: 0000
Positions 45
45: 5th PartNo change length 0
______________________________________
Since part number occurred twice on the segment (a maximum of 25 part number occurrences are allowed), the two ending positions of part number and their corresponding change length were entered. If part number did not occur in the segment, but the segment could be used in a path call enter the database name, segment name and the segment size. The remainder of the fields should be zeroes. New entries to the table requires the occurs statement to be modified. Entries in the table do not have to be in any particular order. A find all on x(45) will determine how many occurrences this table should have. If an error is made the Cobol compiler will catch the error. Internal Key Table The internal key table contains the database name, segment name, the key name, the ending position of the part number and the size to compress. Only the keys that contain part number are entered into this table. An example of an internal key table is as follows:
______________________________________
01 DBD-SEGMENT-KEY-TABLE.
05 DBD-SEG-KEY-TABLE.
10 FILLER PIC X(49) VALUE
`OCPTSDBDSFPARTRTFKPRTNBR0008200000000000000000000`.
12345678901234567890123456789012345678901234567890
1 2 3 4
05 FILLER REDEFINES DBD-SEG-KEY-TABLE.
10 DBD-SEG-KEY-TBL OCCURS 25 TIMES
INDEXED BY DBD-SEG-KEY-INDX.
15 DSKT-DBD-SEG-KEY-NAME
PIC X(24).
15 DSKT-KEY-PART OCCURS 5 TIMES.
20 DSKT-PART-END-POS
PIC 9(4).
20 DSKT-CHNG-LENGTH PIC 9.
______________________________________
In the above example:
______________________________________
Positions 1-8:
Database Name:
OCPTSDBD
Positions 9-16
Segment Name: SFPARTRT
Positions 17-24:
Segment Key Name:
FKPRTNBR
Positions 25-28:
1st PartNo ending position: 0008
Positions 29-29:
1st PartNo change length 2
Positions 30-33:
2nd PartNo ending position: 0000
Positions 34--34:
2nd PartNo change length 0
Positions 35-38:
3rd PartNo ending position: 0000
Positions 39-39:
3rd PartNo change length 0
Positions 40-43:
4th PartNo ending position: 0000
Positions 44--44:
4th PartNo change length 0
Positions 45-48:
5th PartNo ending position: 0000
Positions 49--49:
5th PartNo change length 0
______________________________________
Entries need to be made to this table only if the key to the segment or the alternate key contain a part number. If a key is concatenated (with 2 or more part numbers or a part number and something else like a date), the position is entered where the part number(s) ends (a maximum of 25 part number occurrences are allowed). A find all on x(49) will determine how many occurrences this table should have. If an error is made the Cobol compiler detects the error. The following is an example of an SSA:
__________________________________________________________________________
01
SSA-QUAL-SFPARTRT-SEGMENT.
05 SSA-QUAL-SFPARTRT-SEG-NAME
PIC X(08) VALUE `SFPARTRT`.
05 SSA-QUAL-SFPARTRT-QUAL
PIC X(01) VALUE `(`.
05 SSA-QUAL-SFPARTRT-KEY-NAME
PIC X(08) VALUE `FKPRTNBR`.
05 SSA-QUAL-SFPARTRT-OPER
PIC X(02) VALUE `=`.
05 SSA-QUAL-SFPARTRT-KEY
PIC X(10) VALUE SPACES.
05 SSA-QUAL-SFPARTRT-END
PiC X(01) VALUE `)`.
__________________________________________________________________________
In this example, FKPRTNMBR is the key to the SFPARTRT segment in the OCPTSDBD database. The length of the part number defined to IMS is 8 (application program will pass a 10 position part number) and the size is to be truncated 2 positions. Once changes in a partition have been implemented, unit, string, and subsystem testing is conducted. The unit testing is generally conducted by the individual making the actual code modifications of a single object. It involves simulating program input and output, allowing verification that the program internals are correctly functioning. The string testing involved testing interdependencies between highly related programs. If one program writes to a file, and a program reads from the same file, a string test ensures both programs are using the proper format. Subsystem testing is string testing with the use of actual data used during system operation. This verifies that the functions work as defined by the customers and that the system operates on all permutations of data. Lastly, in the case of large partitions, multiple inter-related systems were testing in conjunction. This is a production test, performed on the day the programs are incorporated for actual production, and ensures that programs function to support existing processes. If a failure occurs at this level of test, the entire partition is backed out of production. The last step in the redevelopment process entails implementing each changed partition. This occurs after a programmer knows which production elements are going to modified, and a DCCS project is created which includes all the specific elements to be changed. FIG. 27 shows the program and data flow between the DCCS 800 and the Redevelopment data base 802. Prior to implementing a change to a particular program (or data file), a copy of the program 804 to be modified is obtained from the DCCS 800, and "signed out" by the programmer. This prohibits the existence of multiple copies being changed by different groups or programmers. After the changes are made and successfully tested, the modified program 806 is signed back into the DCCS 800. After all the programs and data files of a given partition are signed back into the DCCS 800, the partition owner establishes a production date for implementation. When the DCCS project implementation date matches the current date, elements are transferred to the software library 808. In most cases, the current executing programs and data files are moved to a history file 810 that may be used to back the changed objects out if a problem is discovered. The status of production implementation is recorded in the DCCS 800 so that the owning programmer of the project and production operation personnel can track the project status. As the DCCs 800 records production implementation, the indication of a production transfer is used to communicate to the redevelopment database 802 that a change has been made. The redevelopment database 802 retrieves the relational information concerning the elements which have changed, and updates the redevelopment tables 812 to reflect the changes. This update is executed nightly to keep the redevelopment data base as current as possible. From the foregoing, it will be seen that the present invention provides a complete system and process for conducting large scale modifications to large software systems. The system is capable of being integrated with a wide variety of information systems. Therefore, while the invention is illustration and described in conjunction with a certain information system and a specific software change, it will be understood that the principles of the invention can be adapted to virtually any Information system and software change. Accordingly, it should be understood that the present invention is capable of certain modification and change without departing from the spirit of the invention as set forth in the appended claims. ##SPC1##
__________________________________________________________________________
APPENDIX 3
__________________________________________________________________________
Function prtnrListMoveForward (anElementID As Long, listSize As
Long, listStart As Long, listEnd As Long)
Dim tl As Integer, t2 As Integer, anIndexID1 As Integer,
anIndexID2 As Integer,
anElementID1 As Integer, anElementID2 As Integer
Dim anIndexID As Long
`ONLY MOVE IF ITS NOT ALREADY AT BEGINNING OF LIST
If anElementID < > listStart Then
`FIND FIRST ELEMENT THAT HAS A GREATER SCORE
prtnrListConvert anElementID, anElementID1, anElementID2
anIndex ID - Elements (anElementID1, anElementID2) .Previous
prtnrListConvert anIndexID, anIndexID1, anIndexID2
Do While (Elements(anElementID1, anElementID2) .Score >
Elements(anIndexID1, an IndexID2) .Score)
`CHECK FOR BEGINNING OF LIST
If (anIndexID = listStart) Then
`DELETE THEN ADD ELEMENT TO BEGINNING OF LIST
x - prtnrListDelete(anElementID, listSize,
listStart, listEnd)
x - prtnrListAddFromStart(anElementID, listSize,
listStart, listEnd)
Exit Function
End If
anIndexID = Elements(anIndexID1, anIndexID2) .Previous
prtnrListConvert anIndexID, anIndexID1, anIndexID2
Loop
`CHANGE POINTERS ONLY IF IT HAS MOVED
If anIndexID < > Elements(anElementID1, anElementID2) .Previous
Then
x - prtnrListDelete (anElementID, listSize, listStart, listEnd)
Elements(anElementID1, anElementID2) .Next
Elements (anIndexID1, anIndexID2) .Next
prtnrListConvertElements(anIndexID1, anIndexID2) .Next, t1, t2
Elements(t1, t2) .Previous = anElementID
Elements(anIndexID1, anIndexID2) .Next = anElementID
Elements(anElementID1, anElementID2) .Previous = anIndexID
listSize = listSize + 1
End If
End If
End Function
__________________________________________________________________________
|
Same subclass Same class Consider this |
||||||||||