EnterApp

Web Services Council

Enterprise Applications
Development Guidelines and Procedures

System Maintenance

Primary Responsibility

It is the responsibility of the individual to whom a system is assigned to provide customers with a fully functioning system, to keep an orderly set of files, and to assist customers with any problems they may encounter while working with the system. It is also the IT staff member's responsibility to maintain and update the system documentation and ensure that all on-line documentation is updated. The status of each system must be checked regularly and maintenance performed to ensure old data is promptly removed, capacities are adequate for future processing, integrity is maintained, and performance is adequate.

Backup Responsibility

It is the responsibility of the backup analyst or IT staff member with backup responsibilities to review the system manual and to become knowledgeable to the extent that customers may be assisted with many of their problems during the absence of the primary analyst. In the absence of the primary and backup analyst all user contact should be referred to the Manager of Administrative Systems.

Major Changes Reviewed

When a structural change is required to a database, a copy of the schema should be given to management for review. Changes should be highlighted. Additionally, the individual with backup responsibility should review the change. Changes to a database have far reaching consequences and must never be performed without consulting other IT staff members.

Robot Utilization Recommended

When significant changes are made to a system, a search of all files impacted by the change can often be performed by use of the Robot cross-referencing utility. It is the responsibility of each IT staff member to become familiar with Robot and use it as required to avoid errors in oversight.

Inter-System Interfacing

Since many systems interface with other systems there are no well defined boundaries to establish the individual responsible for modifications. As a general guide any program in a system which modifies data in a database for which you are not responsible should be reviewed by the individual responsible for the other system as well before being placed in production. Responsibilities lie with the system to which a program is assigned, not with the group or customer who is given use of such a program.

Responsibility for Updates

Updates or changes to existing programs must be approved by the IT staff member in charge of the system. In the event of his/her absence changes must be approved by the designated backup analyst. Any individual performing backup responsibilities for another during their absence should send an email message or otherwise provide timely information to the responsible person concerning any action taken. In the absence of the primary and backup analyst all user contact should be referred to the Manager of Administrative System.

The procedure to be used for modifications is as follows:

  1. A procedure on the DESIGN account has been created which establishes an easy method for following standards for revision of source code. The command CHECKOUT issued from QEDIT walks you through the process by creating a copy in the SOLD (SourceOLD) group and a copy in your personal group. It then purges the original from the source group you selected. A similar procedure, CHECKIN, renames your source file into the source group you specify. An SCOMPARE batch job is then created. The listings of the SCOMPARE run are to be stored for later review. The old version remains in SOLD until it is replaced by a later checkout of the source code. An old copy of object code may be placed in ANALYST for a short time to ensure quick replacement to the original if necessary. A copy of object code should not be necessary for most programs.
  2. A similar procedure on all production accounts has been created for use with streamx jobs and on-line non-compiled programs. The command CHECKOUT issued from QEDIT walks through the process by creating a copy of a program file in the SOLD.hpaccount group and a copy in your personal group. It then purges the original program file from the group selected. A similar procedure, CHECKIN, renames a program file into the group specified. No SCOMPARE job is created. The old version remains in SOLD until it is replaced by a later checkout of the program file.
  3. All modifications required will first be made to a test version of the program.
  4. Only after testing, documentation, and any additional customer training are completed is the program to be placed into production. At that time, in the case of object code files, its former counterpart is to be purged from the system.
  5. Any interface with a system outside one's area of responsibility should be cleared with the IT staff member responsible for that system. A restore of any file, by a IT staff member, outside of their expressed responsibility, is not generally permitted.
  6. All routine recurring maintenance jobs should be scheduled through the JobTime scheduling software available on the HP3000. If this is not possible the customer maintains primary responsibility for such jobs.
  7. Any software updates received directly in the mail must be reported promptly to the Manager of Administrative Systems. Secretaries have been directed to give tapes received in the mail directly to the Manager; however, since that is not always possible each IT staff member will be expected to report it. This is required to allow management to participate in priority setting.