In-House Changes

Policy

The official policy regarding in-house changes is that they will not be made unless necessary to conform to state law. SCT indicates that its programs will conform to federal law.

There are situations when a program must be changed. It may be necessary to change a program to have it fit within the AU system. For example, the main ZSS online control program is adapted to fetch logon information from RACF.

Some copy members are also intended to be changed. For example, a copy member in the Accounts Payable System that handles annual IRS Form 1099 reporting must contain information specific to Auburn University. There are other examples, but they are not frequent.

Other changes to the system are to be approved by the appropriate steering committee. Since these do not currently exist, it is usually requested that the appropriate vice-president sign off on the change. It is probably better to try to convince the user not to ask for the change. SCT software is not inexpensive. Purchase of a software package is also purchase of its underlying philosophy. Program changes can distort this. In addition, it becomes more difficult to track changes as more are made.

If a change is needed for internal reasons, normally permission is sought from the Director of Information Systems.

Types of Changes

There are different types of changes. Some are designed to be made while others are not.

DBD Changes: Changes to the delivered data element table (DBD) are expected. Often new variables must be defined as well as new data translation values. When these changes are made, a change log entry is made among the comments of a data element indicating the change that was made. When a new DBD member is delivered by SCT, this internal documentation makes reapplication of changes much easier.
Screen and Procedure Changes: Changes have always been expected in online screens and procedures. One of the most common changes to an online procedure is to add an audit step. This should be documented in the same fashion as programs (see below). Screens are frequently changed for better functionality, to eliminate unused data elements and to add new data elements. When a screen is changed, generally the date of the change (in MM.DD.YY format) is put in the lower right hand corner of the screen. If that is not possible, place it in the lower left corner. SCT delivers screen changes in a format that will replace the existing screen (and thus all of its changes). Placing the date on the screen provides a quick visual confirmation as to whether the automatic screen change process can be used or whether the screen must be manually changed.
Program Changes: All Cobol programs should use a change log. When SCT programs are unloaded and placed in Panvalet libraries, a change log is automatically inserted at the top of the program. Any program change should follow standards, which means a change log entry and the initials and month/year of change in columns 73-80 of program lines changed.
In addiiton, the changes are recorded and placed on the DUC network in the g:\adcs\everyone\vendor\changes directory. Changes are stored by system and subsystem. The general format is a header similar to the change log followed by a brief description of the change and why it was necessary. This is followed by screen prints of the changes, including enough information to determine paragraph and location in the program. If there were previous changes to the program, add the new information to the end of the file rather than create a new file. This process is quite important. When a new version of a system is installed or if a new copy of an existing program is delivered by SCT, this is how changes are reapplied.

OIT Applications Support

Last Modified: Tuesday, 28-Nov-2000 11:07:33 CST