Browse Prior Art Database

Change Detection Via CSECT Comparison

IP.com Disclosure Number: IPCOM000110619D
Original Publication Date: 1992-Dec-01
Included in the Prior Art Database: 2005-Mar-25
Document File: 4 page(s) / 188K

Publishing Venue

IBM

Related People

Ludlow, DM: AUTHOR

Abstract

Traditional comparison techniques to determine when a change has been made in a file are time consuming and also of limited utility, especially with large files. Comparing an entire file comprising text, control code, comments, and the like in a first version of a program against a second version of the program can be done on a bit, byte, word, line, file, or any other boundary or increment to detect changes or differences between the two versions.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 41% of the total text.

Change Detection Via CSECT Comparison

       Traditional comparison techniques to determine when a
change has been made in a file are time consuming and also of limited
utility, especially with large files.  Comparing an entire file
comprising text, control code, comments, and the like in a first
version of a program against a second version of the program can be
done on a bit, byte, word, line, file, or any other boundary or
increment to detect changes or differences between the two versions.
However, this is not useful when, for example, an intended change
such as a bug fix to one element of the file propagates to numerous
others via normal operation of the program and its control codes so
that comparison of the other segments or sections will also show
differences, since this vastly amplifies the task of uncovering the
differences that may be important during failure analysis tasks.

      As shown in Fig. 1, a simple solution is to identify CSECTs
(control sections) that are created within main program source files
as the logical search and comparison boundaries.  As shown in Fig. 1,
typical source programs 1A-1N may be composed of many source
subprograms that are individually translated, compiled, and assembled
into a process efficiently and saved as a load module ready for
execution.  The steps of processing are shown schematically in steps
1-5, in which the program source elements are first created in block
1, compiled in block 2, assembled in block 3A, and converted to
program object text or code in block 4, and then link edited into
block 5 into executable format, which may be stored in storage 6 for
execution in segments called load modules, via unloading through
loader 7 or to an application program in C language for eventual
execution in block 8, or a CSECT comparison of the listing as shown
in block 8B.

      CSECTs are main program source element names and identifiers
which are created by the programmers who make the selection of names
of main program process elements during creation of the program
source material.  In the assembler 3, the CSECTs are identified from
the program material and listed in a directory section identifying
where each CSECT can be found in the program object text as edited by
the link editor, etc.  CSECTs contain both control information or
data and program data or code.  An encoding within the CSECT
identifies which code records belong in each category of control or
program data.  Control information is needed to instruct the loading
of the sections of code relative to the starting load addresses for
the overall large program to be executed.  The program data is itself
a transformation of the original source text, excluding addresses
that would make the data non-relocatable.

      Changes to any portion of the code can be introduced in several
ways.  First, the original code source may be changed.  Second,
another element within the load module may be changed, and it may
co...