Browse Prior Art Database

Processing a Proprietary Statement in a Module Disclosure Number: IPCOM000108954D
Original Publication Date: 1992-Jul-01
Included in the Prior Art Database: 2005-Mar-23
Document File: 4 page(s) / 144K

Publishing Venue


Related People



The invention disclosed is a software tool which enables the convenient rewriting of prologue statements in a newly released software module.

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

Processing a Proprietary Statement in a Module

       The invention disclosed is a software tool which enables
the convenient rewriting of prologue statements in a newly released
software module.

      One needs to include a proprietary protection statement, such
as a copyright statement, into all software modules.  The proprietary
statement tends to change over time because of changing dates,
protection level, or new releases.  For example, when a module is
under development, it will have a company proprietary statement in
it.  Should the module source be shipped to the customer, the
proprietary statement will need to be changed to a copyright
statement.  The changing of the proprietary statement will be easy
for a few modules, but it will be time consuming for a lot of

      To process a proprietary statement in a module, one needs the
ability to insert, change, and delete a proprietary statement.  Also,
to insure that you have not made a mistake in entering the
proprietary statement, you need the ability to check for the correct
proprietary statement.

      The ability to insert, change, check, and delete a proprietary
statement necessitates that the program understand how the
proprietary statement is placed in the module.  Since the proprietary
statement is not run in the module, the statement is placed inside of
a language comment statement.  The program needs to determine the
particular comment structure in the module in order to find the
proprietary statement.  The program also needs to be able to generate
a proper comment statement for the module.

      The automation of this task using traditional programming
techniques is rather arduous, if not impossible, because comment
delimiter characters change from computer language to computer
language.  For example, in 370 assembler you use an asterisk ('*'),
and in PL/1 you use slash asterisk and asterisk slash combinations
('/*' '*/').  Commenting styles may vary from programmer to
programmer.  For example, the slash asterisk and asterisk slash
combinations ('/*' '*/') allows a lot of freedom for the programmer
to develop unique programming styles.

      With traditional programming, you need to code in all the
logical decisions when the module is written.  The module cannot
adapt to the style of coding used by the programmer.  The real
difficulty with a traditional programming approach is that you do not
know all the styles of a prologue that can be taken by various
programmers.  You might try asking the programmer what style the
programmer chose from a list of styles that you have coded.  You
might ask the programmer what programming language and style he or
she used, but then, when a new language or even a new programmer
comes along, you will have to change your function when dealing with
proprietary statements.  This can easily turn out to be a
never-ending process as there are always new programming languages
and new programmers...