www.HowardPowers.com
Resume addendum: Sabre CDN - MEP/DDP System

Background

The Y2K certification analysis for Canadian Air materials management system (MEP/DDP) was completed in the summer of 1998 under the assumption that the system (including internal IEF routines) was a standard IMS/DB2 COBOL system which could be modified in the standard ways. SABRE was uncomfortable with that assessment and requested that two IEF resources be brought on board for a three month period of time to handle the steps required for certification. During the interview process (September 1998) I recommended the following approach to SABRE:

  1. Generate encyclopedia level where used report against all entity attributes of type DATE.
  2. Create an Access database cross referencing these attributes to Action diagrams.
  3. Review the each attribute - action diagram tuple for Y2K compliance.

SABRE accepted that approach, however, since I was on or near the critical path for two separate SAP module implementations (payables and materials management) at MOBIL, I could not leave before the second (and most crucial) phase of the MOBIL-SAP implementation was in production. This Occurred on Jan 1, 1999. My last official day at MOBIL was Jan. 3 1999. My first day at SPR was Jan. 4, 1999. In spite of the six month lead time, SPR was unable to procure another IEF resource for the job.

The system was approximately five years old. The object modules had not been regenerated through several encyclopedia upgrades. The system did not have a normal IEF maintenance team. The system also did not have a normal development tso region (i.e. data sets, pds's, JCL, DB2 tables etc.). The system encyclopedia pointers were not set up for maintenance activities. The analysis document was not set up for a code generated system. The only system documentation available was part of the on-line screens. We also had the analysis document which listed production lib member names.

The existing generated code was not certifiable and the encyclopedia action diagram dates could not be correlated with object module dates. The decision was made, therefore, to fully test the system to develop a base line then regenerate the system and re-test to insure the integrity of that baseline before proceeding with the certification process. The certification process involved line by line review of the appropriate code, then object by object migrations (using OM) into three separate TSO regions with associated IMS regions for Y2K testing.

Other Resources

Since the project was a SPR-Tulsa project that office provided a senior manager for the project. Since the work was performed at SPR-Irving, that office provided a project manager. When it became obvious that no other IEF resources (acceptable to the client) could be found SPR-Irving also provided a mainframe programmer to assist with the non-IEF portions of the project. A SABRE manager assumed the role of client and also made available both a senior IMS-DB2 application DBA for system level technical support and an encyclopedia support vendor for model migration into the development encyclopedia and system level IEF support. SABRE's project management office provided support for the project plan. Communications support for weekly conference-call status meetings was also provided by SABRE. No overtime was allowed on the project.

My role

I was given complete technical control of the project. My tasks included the following:

  1. Develop the approach used on the project.
  2. Provide task list and initial estimates.
  3. Communicate project status, problems and progress to SABRE.
  4. Interview mainframe programmers to find an acceptable resource to assist with the project.
  5. Approve the resource selected.
  6. Outline initial test strategies.
  7. Review the data base and logic to develop viable live test data for the online system.
  8. Review the data base and logic to develop test verification spufi's for the batch system.
  9. Create verification spufi's
  10. Review entity types to obtain attributes of type DATE.
  11. Review workset attributes to obtain attributes of type DATE
  12. Create where used reports for each DATE attribute.
  13. Edit where used reports for to obtain attribute/action diagram references for loading into Access.
  14. Create cross reference tables.
  15. Set up all encyclopedia pointers for system regeneration.
  16. Set up all data sets, files, JCL and procs for initial base line tests.
  17. Regenerate the system including external stubs.
  18. Recreate externals from regenerated stubs.
  19. Correct the coding errors introduced by regenerating the stubs
  20. Correct the DB2 preprocessor errors introduced by regenerating the code. (No not timestamp, although that did rear it's ugly head in some of the test regions)
  21. Review each action block listed in the cross reference table. Find each reference for each date attribute to insure that no Y2K violations occur.
  22. Define each object within the system to the object manager system.
  23. Migrate each object into the various test regions.
  24. Set up each test region.
  25. Interpret test results.
"back to resume"

10/11/99 Howard Powers

Made with cascading style sheets Valid CSS! Valid XHTML 1.0! ATT provided counter Page hits since 12/05/2000