Year 2000 Last Minute Error Elimination
Software Audit and Due Diligence Process

Alydaar Software Corporation, an Information Architects Company

Introduction

Purpose of this Document

The purpose of this summary is to provide a high level overview of audit activities and deliverables for verifying Year 2000 compliance in client code.

This document is intended to demonstrate the roles and responsibilities of the participants in addition to the activities throughout the audit process. It provides brief information of the necessary steps for an audit process, starting with client activities, continuing through the audit factory, and ending with the final deliverable to the client.

What is an Audit?

When verification of Year 2000 (Y2K) compliance is required for an application, an audit should be performed. An audit is more than running test data through an application, it is a line-by-line verification of the application code itself for Y2K functionality.

Audit results verify that the date variables used in the application function correctly now and beyond the Year 2000. In addition, it supplies identification of specific reference points within client code where current logic will not function properly in the new millennium.

This audit can be performed on pre- or post-compliant applications as well as expanded and non-expanded code. In either case the process is similar. The bottom line of an audit should verify two things:

• Date variable usage within code is Year 2000 compliant.

• Non-Year 2000 compliant dates are remediated accurately and consistently throughout the code.

Audit Services Necessary

An audit service provider should offer two levels of audit services:

1. Line-by-Line (Including all data sources)

2. Line-by-Line (Excluding all data sources)

A summary of each service is noted below.

Option One - Line-by-Line (including all databases/data sources)

Option One is the most complete audit process. Accordingly, it is the most time-consuming and costly. With this option, all Year 2000 failures in failure scenario statements are identified in the chunk of code including an audit of dates in database, VSAM, IDMS, ADABAS, etc. keys. This option is most valuable to a client who desires a complete, thorough audit and report of their applications.

Option Two - Line-by-Line (excluding data sources)

In a Line-by-Line audit, each executable statement is scanned to determine pass or fail based on the audit rule set. Data sources, such as VSAM, IDMS, ADABAS, are excluded from this process. When a Year 2000 failure is detected in a program, the statement is marked as "failed", and audit processing continues. This option is most valuable when the client code has little database interaction and/or the client is willing to verify compliance in the databases/data sources involved.

Audit Approach

The service provider�s audit approach involves analyzing the client�s code to identify the failure scenario statements containing dates in the code and then to verify the compliance of the date variables in those statements. These failure scenario statements are those which may cause errors when dates cross the century boundary.

General

Upon beginning the audit effort by an audit service provider, there are certain assumptions that are made by the audit team:

• Any necessary contractual agreements are in place between the client and the service provider, including work orders.

• A non-disclosure agreement is in place with the client.

• The "chunk" of code (Logical Work Unit) to be audited has been compiled by the client and is properly packaged.

• A resource has been assigned by the client to answer application specific questions posed by the Audit team. Normally this should not take more than 1 to 2 hours per week of the client�s time.

Client Preparation

1. Assign Client Resources

The client assigns key resources for the entire audit cycle � through delivery of the final reports. It should be noted that the roles mentioned below could be assumed by a different combination of individuals. In some instances, a single person could fill multiple roles.

Project Sponsor

The Project Sponsor is the senior executive in the client organization who has overall responsibility for the project at the corporate level. The Project Sponsor has little ongoing involvement with the audit project, except to be informed of its status and any issues involving the audit.

Project Manager

The organization or company should assign an overall project manager to run the daily activities of the project. The application team planning to have their source code audited utilizing the Year 2000 audit production facility should assign an individual to the Project Manager role. The responsibility of the Project Manager is to act as the central point for addressing questions as they arise during the audit process. The questions may be either technical or business specific, and will pertain to the particular chunk of code being audited. The Project Manager will need to research issues as they are presented, reviewing them with the appropriate personnel.

The Project Manager is the person with whom the Client Manager (see Section 5) will interface to resolve issues for any given chunk of code that is in the audit process. It is expected that all issues that come from the audit process will be turned over to the Project Manager for resolution within two business days. This is important to keep the chunk processing on schedule.

There may be sub-project managers responsible for a line of business or a specific chunk of code that report to the overall project manager.

Application Specialist

Each chunk of code being audited should have an Application Specialist assigned by the client. It is expected that this individual has an expert or working knowledge of the chunk and can answer questions that arise during the audit process.

2. Determine Audit Requirements

During this activity, the details of the audit steps are defined. The type of audit is determined based on the client�s business needs:

• Option one - Line-by-Line (including data sources)

• Option two - Line-by-Line (excluding data sources)

3. Identify Source Modules

Prior to delivery of the chunk, all source and copybooks, includes, modules, macros, etc. should be isolated into a complete stand-alone package and compiled. This package should be self-contained so as to represent an identifiable section of application software and provide meaningful test results.

4. Finalize and Transmit Packaged Code and Audit Requirements

The Packaging Requirements checklist for the particular platform/language is utilized to verify that all items needed for the audit activities are included. It is very important that attention be paid to completeness and accuracy in content and format.

Additionally, any specific audit requirements for this particular chunk should be forwarded to the Client Manager. Since the audit service provider is not familiar with the client�s code, any additional information that could be supplied with these requirements is helpful. Some examples are:

• terminology

• unusual date constructs or date variables

At this point in time, the client�s preparatory actions are complete and processing begins at the audit factory.

Factory Processing

5. Project Startup

This is the initial phase of audit activity at the Audit Production Facility, and may be initiated in parallel with some of the previous client activities. Before any processing can begin on the client�s code, resource assignments must be made. The audit service provider primary resources are assigned for the duration of the audit effort.

A second activity of the Project Startup activity is the delivery of an initial set of audit rules to the client. This list identifies the pass/fail criteria that the audit service provider will use to process the client�s code. In addition, any client requested criteria that have been agreed upon by both parties should be added to the rule set.

Since this phase overlaps with some portion of the client Preparatory Phase activities, the completion of some of the Project Startup activities may have already been accomplished.

5.1 Assign Resources

As part of the initial activities involving the startup of a project at the Production Facility, resources are assigned. Factors in the decision involve resource availability, skills of the particular team in relation to the client software language(s), client schedule needs, etc. The description of the roles of the Client Manager (CM), Client Services Manager (CSM) and Audit Team follows.

Client Manager

The audit service provider will assign an individual to serve as the Client Manager for each client. The responsibility of this individual is to manage the audit process between the Audit Production Facility and the client organization. This includes:

• documenting all discussions and meetings between the Production Facility and the client;

• working with the client�s Application Specialist to define any unique rules that will be applied against the chunk being audited;

• communicating and resolving any issues that arise during the audit process with the client through the Project Manager;

• tracking Time Out conditions for each chunk during the audit process;

• working with the Audit Team to interpret the business rules for the audit process;

• participate in the quality check process for the audit effort.

The Client Manager is the single point of contact between the Production Facility and the client.

The CM is responsible for working with the Client Services Manager (see below) to document all output from the Production Facility. This includes output which is to be included in the Final Report as well as any output which requires verification by the client. Examples include output from the Line Count and Inventory reports, Rules List, etc. and any questions which the client needs to resolve.

Client Services Manager

The audit service provider will assign a Client Services Manager to the audit activity. The responsibility of this individual is to provide the project management of the chunk during the audit process. This includes managing the Audit Team and any other hardware, software, or human resources used by the Production Facility.

The primary point of contact with the client for the Client Services Manager is the Client Manager. The Client Services Manager will report status and issues to the CM and will work with the CM to document all issues that are identified during the audit process. In some audit projects, the Client Services Manager will actually perform the roles of both the CM and CSM.

Audit Team

The audit service provider will assign a Project Leader and a team of software engineers to work on the chunk in the production facility. These team members will perform the audit process as defined in later sections. The Project Leader reports directly to the Client Services Manager and is the "expert" technician on the team, maintaining quality, accuracy, and timeliness of the audit effort.

5.2 Submit Rules List

The Rules List is a set of standard pass/fail criteria used for the particular type of audit selected by the client. The criteria on this list need to be verified and/or modified by the client prior to the audit work actually beginning. This list is submitted to the client and returned to the Production Facility before the initial chunk of code is sent. Any special requirements by the client must be transmitted to the Client Manager in writing for approval. For these requirements, approval by both parties is required.

6. Inventory and Completeness Check

The first activity upon receiving the packaged chunk from the client is to bring it under configuration management. The media is registered in the Production Facility data library, and client-specific libraries are created on the UNIX system. At this time, an inventory of all received components is performed and any missing components are identified. This aspect of an audit is important since an audit is normally performed for a specific application or system, and all modules for the application or system must be received for the audit results to be completely meaningful.

6.1 Inventory Check

While bringing the chunk under configuration control, the package will be reviewed to ensure that all components have been included. This completeness involves verifying that all modules and the necessary copylibs specified on the source module list have been received. Additionally, a check is performed to ensure that there are no missing called modules. The output from this activity is a portion of the Inventory and Line Count Report.

6.2 Identify Line Count

One of the first activities in the audit process is a count of lines of code delivered to the audit services provider. This particular report is critical since it identifies the extent of the service provider�s involvement in the client�s code. It is in this activity that the remainder of the Inventory and Line Count Report is generated.

If modules are missing after the inventory and completeness check, the client will need to verify that audit of these modules is unnecessary for meaningful results. This is verified during one of the regular status meetings.

7. Verify Rules

This is the point in the audit process where the audit service provider verifies that the audit will be performed to the client�s specifications. A standard list of rules, which are appropriate for the type of audit selected by the client, is updated with any client-specific rules forwarded earlier during the Project Startup phase. During the Verify Rules activity, these updated rules are received by the Audit Team and confirmed prior to actually starting the audit. Client verification of this Rules List is needed before the audit can continue. After this point in time, any changes to the rules are treated as contractual change of direction and subject to the change provisions.

8. Failure Scenario Variable Identification

The initial activity of the audit process is the detection of specific non-century-compliant date variables in failure scenarios that will cause the client code to fail. Audit Phase 1 is a two-step process consisting of detection and nomination. In the detection step, failure scenario statements are identified in the client�s code. After detection, a nomination process utilizing common and client-specific date constructs is performed. The result of these steps is a set of intermediate files that will be used in Audit Phase 2.

9. Automated Identification Verification

Phase 2 is a verification of the results of Phase 1. Certain predefined manual steps take place in this process. Production Facility software engineers investigates the detection and nomination to verify that all date-related dangerous operations are correctly signaled for the audit.

10. Evaluation and Issues Report

This activity will require assistance by the client Project Manager. A report containing any outstanding issues from the project team, after Audit Phase 2 will be sent to the client for clarification of potential problems. This particular report identifies areas that require application programmer expertise to clarify such things as variable breakdown, data format, or potential multi-use variables. This activity is crucial to the Audit Team completing the audit project.

11. Client Response

All issues contained within the Evaluation and Issues report require a written response. It is requested that a response be completed within two business days and provides the appropriate information. The response supplied to the Evaluation and Issues report supplies the final definition of requirements for the audit.

12. Analysis & Verification Processes

The Analysis & Verification processes involve applying the rules that are specific to this client. A number of tools and techniques are utilized to:

• identify conditional issues;

• identify mathematical operation issues;

• identify hard-coded dates;

• identify specific hard-coded century issues;

• identify leap year issues;

• identify embedded date issues;

• identify perform until logic using dates issue;

• identify zeros and 99�s which are used as "flags" (reserved numbers);

• identify any sort issues;

• identify 9�s complement date issues;

• identify any data base/source issues where dates are in keys (if Option One is chosen);

• identify any other requirements that are unique and specific to this client.

12.1 Conditional Issues

The conditional issues occur when two non-compliant dates are used in a comparison operation and each date contains a value of different centuries. If the audit is based on the expansion solution, the audit service provider will ensure both date variables are of the same format and size.

12.2 Mathematical Operation Issues

Mathematical functions using non-compliant dates in their calculations require consideration as well. Something as simple as the statement:

SUBTRACT CURRENT-DATE FROM OLD-DATE GIVING DATE-SPAN

can have disastrous results. If OLD-DATE contains a value of "00" (meaning 2000) and CURRENT-DATE contains a value of "99" (meaning 1999) the result would be "99" and not "01" as it was intended.

12.3 Hard-Coded Dates Issues

Failures occur when a hard-coded date is used for comparison with another date variable and the value contained in the variable is of a different century. If the audit is based on the expansion solution the audit service provider will verify that the hard-coded date has the century added to it. For example:

01 DATE-A PIC 9(6) VALUE 000101.

01 DATE-B PIC 9(8) VALUE 20000101.

IF DATE-A > �991201�

OR

IF DATE-B > �991201�

12.4 Hard-Coded Century Issues

One of the failure scenarios possible includes operators involving hard-coded century constants. Examples of these hard-coded constants could be �019�, �020�, �1900�, �20�, etc. when related to century variables. It is during this activity that these specific hard-coded cases are audited.

12.5 Leap Year Issues

Leap year calculations need verification because the year 2000 is what is termed as a double leap year. A leap year is not only a year divisible by 4, but the century must be divisible by 400 with both calculations having a remainder of 0. For example, 1900 is not a leap year, but 2000 is. Additionally, COBOL 88 level values may require updates or replacement.

12.6 Embedded Date Issues

Sometimes dates are embedded within large record structures, and a comparison of these records is used for various operations. Without identifying these issues, generated data based on these operations can be unreliable.

12.7 Perform Until Issues

Any looping logic that uses date comparisons for the looping condition will fail with non-compliant dates is used.

12.8 Reserved Numbers

The "Reserved Numbers" issue is a situation that is unique to each client. This situation involves the use of a year variable for an alternate meaning or special purpose such as a "flag" or an error message. For these special cases, the programmer has used a two-digit year variable as "00" or "99" for a special condition, not considering the impact of year 1999 or year 2000. An example could be:

IF YY > 00 AND YY < 99

/* do normal treatment */

ELSE

/* do some exception handling */

For these special cases, these statements are identified to the client.

12.9 Sort Issues

A given programmer may interpret certain constructs in a particular language in vastly different ways. An example is the COBOL sort where more extensive investigation is necessary to identify any potential issues of dates in keys.

12.10 Nines Complement Date Issues

The 9�s complement concept is normally used to sequence data in a database or data source. If these non-compliant dates are used then any logical operation containing these variables will fail. The audit service provider needs to ensure that any logical operation containing these will be verified with the client.

12.11 Database Issues

If Option One is chosen for the audit, each database call will need to be examined to identify any issues of dates in keys that are non-compliant.

12.12 Other Client-Specific Requirements

After the Rules Verification step, specific audit requirements may have been identified which may not be typically processed during the normal Audit process. Any of these requirements, which fall out of the normal audit flow, are addressed at this time.

13. Final Report Preparation

After completion of all audit activities, the Final Report is prepared. Based on the audit option chosen by the client, this report may identify modules failed, lines failed, database statements failed, etc. The Final Report is the primary deliverable from the audit process.

14. Final Package Review and Delivery

All components in the delivery package are reviewed for completeness and accuracy. Documentation is examined to verify that all information needed by the client is included.

At this point in time the audit service provider has completed all its planned activity involving the chunk of code. Activities return to the client where they will receive the completed report.

Deliverables

15. Audit Deliverables

The primary deliverables for the audit project are:

• The return of the original code media (If requested)

• Inventory and Line Count Report

• Audit Rules List

• Issues Report

• Final Report

The Final Report contains information compiled during the project by the Audit Team as well as a summary of audit findings.

The sections included in the Final Report are:

• Project Overview

• Application Metrics

• Inventory

• Line Count

• Listing and Definitions of Issues Found

• Listing of Pivot Years

• Failure Scenarios

• Potential Dangerous Operations

• Hard-Coded Date Issues

• Sort Issues

• Database Issues (for Option one)

• Reserved Numbers

• General Issues

Glossary

Chunk - A "chunk" is a grouping of programs and related components that are to be remediated as a single entity. This may be either an entire application or a smaller grouping that can be compiled and tested in a stand-alone environment.

Failure Scenarios - Those operations in a source program that, when coupled with non-year 2000 compliant date variables or constants, will fail. The classic example is the subtract operator. In the case of a subtraction, when a larger number (for example 99, representing 1999) is subtracted from a smaller number (for example 00, representing 2000), the statement will return an invalid result.

Pivot year/variable - A variable with a specific value that will be used for comparison purposes to determine the correct century based on a 100-year window. If the value of the "test variable" is greater than or equal to the value of the pivot variable, then the century associated with that date value is 19xx (current century). If the value of the "test variable" is less than the value of the pivot variable, then the century associated with that date value is 20xx (next century).

Reserved Numbers - A situation where the client has used a year variable for an alternate meaning or special purpose such as a "flag". An example is where the programmer has used the value of a two-digit year variable as "00" or "99" for a special condition, not considering the impact of year 1999 or year 2000.

Windowing - The process of applying a remedy to statements with failure scenario statements that will fail when Year 2000 dates are used. This remedy ensures that operations that manipulate dates will continue to return intended results.

Visit Author's Web Site