Cornell University Electronic Student Records Systems Project Report

return to index

Appendix E: Meetings at Cornell, 24 July — 4 August 2000


  1. Project planning, Elaine Engst and Peter Hirtle, 24 July, 10 am, Kroch Library
  2. Electronic Records Project, Oliver Habicht, 25 July, 4 pm, Kroch Library
  3. Student Records, David Yeh, University Registrar, 26 July, 9 am, Kroch Library
  4. SRRS/SIS, Lynne Personius, Library Systems, 28 July, 9 am, Olin Library
  5. Degree Audit Project, Laurence ‘Mike’ Hammer, Project Manager, 28 July, 2 pm, College of Arts and Sciences
  6. CourseInfo, Joan Falkenberg Getman, Caroline Hecht, Pat Graham, 1 August, 12:30 pm, Computer and Communication Center
  7. Audit Requirements, Barbara Skoblick, University Audit Office, 2 August, 9 am, Toboggan Lodge
  8. Student Records Data Mart, Christopher Cox, Tracey Thompson, University Registrar’s Office, 1 pm, Day Hall
  9. Student Records, David Yeh and Chris Cox, University Registrar, 4 August, 9 am, Day Hall
  10. Cornell systems and Mandarin Project, Graham Hall, 4 August, 11 am, 120 Maple Ave
  11. CornellC backup procedures, Mike Garcia, 4 August, 3:30 pm

Other sessions:

Project overview with Tom Hickerson, Associate University Librarian, Information Technologies and Special Collections, 2 August

Research discussion with Anne Kenney, Preservation and Conservation, 2 August

Research discussion with Sandy Payette, Computer Science, 4 August

Meeting 1: Elaine Engst, University Archivist, and Peter Hirtle, Director CIDC, 24 July 2000


Cornell University received an 18-month grant from the NHPRC in 1998 to identify the policies needed in an academic setting to preserve and provide access to electronic records. The planned implementation of a comprehensive, university-wide system that would incorporate all core university systems, including student records, seemed to provide an ideal opportunity to address electronic records issues. Various factors interfered with the original plan: severe problems with the PeopleSoft implementation, the inability of University management to address archival questions and concerns due to the crisis created by the software implementation failure; and the lack of understanding by the University of archival concerns. Due in large part to the efforts of the Archives and the failure of the software implementation, the University is much more receptive to archival concerns now.

Given that the software implementation is stalled, it was not possible to complete the NHPRC project as planned. The project, with input from NHPRC, was restructured to focus on defining archival requirements for electronic student records systems. At Cornell, the current student records are still running in the old system that was developed around 1980. There are hard copy records in the Archives for the period through 1979.

Scope of project:

The restructured project will produce a report that will primarily address archival metadata, system functionality, system documentation and other requirements to support and enable longterm access, but the report may consider areas such as the implications of data warehouses for student records and issues surrounding PeopleSoft for student records systems.

The report will:

The project will also provide, to the extent possible, recommendations that are specific to Cornell and can be used when the new student records system is implemented.

The report will not address student:

Considerations for student records systems that the report may address:

What information should be retained about students over time?

What changes to individual records should be retained and at what points?

What long-term access (research) needs are there for student records and how can those needs be met?

How could/should the system address individuals who have different roles at a University over time, e.g. student, alumni, employee, faculty?

What is the relationship between the Archives and the Registrar for the provision of official (and unofficial) transcripts over time?

Relevant projects to consider:

Indiana University student records project

University of Michigan student records project

InterPARES case study on student records

Preliminary sources that may be relevant to the project:

Minnesota Electronic Records Project

Australia’s DIRKS manual: Designing and Implementing Record Keeping Systems

AACRAO publications

Meeting 2: Oliver Habicht, Director of Desktop Services, 25 July 2000

Oliver worked part-time on the ER Project. He attended some of the meetings. He has notes on all of the meetings he attended. He never could get documentation or detailed information of any kind for the current or proposed system so he could not provide much input.

His notes on the meeting with the Registrar 1/19/99:

Before 1978, microfilm and hard copy

Audit data on load

Case by case migration not wholesale [migrate records as needed not all]

Stored to tapes — frozen files — 3rd week of classes and end of semester

Microfilm vs. magnetic tape [longevity- microfilm viewed as more reliable]

Student academic records — 5 sets

  1. Student Record System (SRS), 1978-1979. Still used

    Student Information System (SIS), 1983- too costly, not finished

  2. Undergraduate Admissions
  3. Financial Systems [not part of project]
  4. Bursar [not part of project]
  5. Graduate

[These are stovepipe systems]

Goal: reduce redundancy over time

PeopleSoft would be a central repository for 5 systems

Whatever is in SIS [SRS] is the baseline

Choice: All old data vs. necessary data

Planned implementation January 2000 [system implementation was halted]


Operational system. [all the buzzwords for functionality]

Produce transcripts using a reporting tool, a view of the data

Historic data- point-in-time access for effective dating

Data dictionary

Registrar recommended meeting with Director of Institutional Planning and Research

His notes on preparing for the meeting with the Registrar with Elaine, Cheryl S-B and Eileen:

Provided date spans for microfilm, hard copies from Archives inventory

Reviewed costs of not addressing archival issues [to make case to Registrar]

Maintain vs. migration

Institutional memory

Legal- retention

Goal preserve history, memory

He provided copies of:

Cornell ER project materials

Indiana University ER project materials

ECURE meeting

Saffady book

Meeting 3: David Yeh, University Registrar, 26 July 2000

Scope: Dealing with more than just traditional student records now: also admissions, financial aid, etc.

Long-term access:

Planning: There is a need to balance day-to-day pressures vs. long-term planning, and sometimes a need to address the long-term now to enable day-to-day

Patent renewals: one reason for retrospective retrieval. Alumni must document credentials for patent renewal, licenses, and certification. This may require getting down to descriptions of courses taken.

Storage: COM is a stable media and supports operational uses- retrieval

Imaging: They have looked at imaging for admissions. This would allow information about accepted students to be captured at the start. Now hard copy folders are circulated. Electronic versions would raise many confidentiality concerns but it would be possible to build a method that would support circulation and confidentiality.

Implementation issues: The end of the P2K project provides an opportunity to step back and consider workflows, needs, etc.:

Current status: Discussion: Next step: Christopher Cox and/or Tracey Thompson can provide information on the datamart

Meeting 4: Lynne Personius, Library Systems, 28 July 2000

Lynne has been at Cornell since 1969. She started with CIT, worked for the Registrar briefly, returned to CIT for a time then transferred to Library Systems where she has been since. She worked at IBM for five years before coming to Cornell.

When she arrived in 1969, student records were set up in a 1401 configuration to run punchcards. Students placed their cards behind the cards for courses they would attend. An application in Autocoder language produced course lists. Cornell did not have a 1401 so someone wrote an Autocoder emulator to run on a 360. The system was in crisis mode.

The Registrar contracted with SCT to build the Student Records and Registration System (SRRS). A large sum was allocated to the project but he system was not successfully implemented. Lynne agreed to work on a batch system to support the function. The system was not popular because expectations were so high for the SRRS. She believes that the exam scheduler from the batch system is still used.

The student records system has been augmented since then and no money was allocated to it until the attempted PeopleSoft implementation. The Student Information System is an on-line system that has ADABAS modules. It still references parts of the SRRS batch system. The Registrar designed SIS. CIT supports tape archiving. All administrative systems have a backup plan. SIS (SRRS) is still on the mainframe.

Lynne recommends meeting with Cindy Pataki who has worked with the student records system for 20 years at CIT and ASDT. She also worked on the PeopleSoft project. She would have information on the status of the system.

Lynne mentioned the difficulty of IDs for the various systems in verifying information for the Library systems. SIS uses Social Security Numbers. The Bursar uses a six-digit number that probably goes back to the 1401 system. HR has a different ID that is randomly assigned.

As for PeopleSoft, the first module that was abandoned was the Accounting module. Then, the Payroll module was implemented but required work-arounds by Cornell staff for time cards and other pieces.

A Rochester company called Information Associates built the Financial Aid and Bursar systems that are still used.

Meeting 5: Laurence ‘Mike’ Hammer’, College of Arts and Sciences Computer Systems, 28 July 2000

Topic: degree audit project

The College of Arts and Sciences is the largest college. They have 42 departments and 50-60 possible degrees. They teach 53 foreign languages. They need a system to manage degree requirements for the students. They are reprogramming their existing degree audit system because the software that it was built in will be unsupported and unsupportable in 5 years. They have a goal of 2 _ years to redo the system. They are talking to other colleges about participation. At this point, CALS, Engineering and possibly ILR will participate. Human Ecology will not participate, for example, because, as a much smaller college, it would probably be easier to manage their requirements manually. Other colleges may participate. Arts and Sciences will develop the new degree audit system and provide an instance of the code to the participating colleges. At that point, each college may adapt and evolve it as needed, but upgrades and enhancements will probably be circulated.

Degree Audit System background:
The existing system replaced the manual Personal Record Cards (PRC) system. The PRC cards contain a grid partitioned into parts 1-4 that match the degree requirements. There is a University writing requirement to track, ‘part 0’, in addition to the 4 parts. The Course Listing catalog lists the entrance, placement and distribution (degree) requirements for each Department in each College. Students are required to meet the requirements that were in place when they began the program. This means that the degree audit system must track changes in courses, changes in degree requirements and changes in courses needed to meet requirements for degrees to insure that each student has an accurate listing of requirements met and requirements needed.

System conversion:
The current system, SPUDS, was developed in 1988. The data is reliable from 1989-on. SPUDS written DOS-based, proprietary database software called Revelation, which as last updated in 1989. SPUDS will be rewritten in VisualFox for SQLServer. Both are Microsoft products. The new SPUDS will be fully relational and run on NT. They will do a 100% conversion of the current data and will continue to maintain the data on-line or near-line because there is not a huge amount of data to store. The system rewrite will require 4 man-years of coding. [For comparison, 50 programmers worked on PeopleSoft for two years.]

SPUDS does contain some confidential information. Advisory Deans make notes on events and situations that are relevant to the status of the student in the program. For example, mental health assessments as they pertain to the ability of the student to continue in or complete the program are included. These are stored as separate text notes and are stored near-line. They get perhaps two requests in five years for that require access to this information.

System maintenance:
SPUDS, and all of the Arts and Sciences systems are backed up once a week. One monthly backup is retained as well as a six month baseline.

Screens and Access:
Anyone who has access to the Student System has access to SPUDS. There is screen-level and field-level security. There are 4 screens:

  1. Main Degree Audit: student identification, major, advisor, academic actions (e.g. semester off, etc.)
  2. Advisory Notes
  3. Credits: course counts
  4. Graduation screen: Department certification of Major
    Access to screen 2 is very limited. Screen 4 is important because students could complete University and College requirements and still not satisfy major requirements. SPUDS produces reports to document graduation progress. Most access is read-only. Advisory Deans are allowed to enter data into Screen 2.

Data Entry:
Data entry is difficult because users have to know what to enter and there is very little field validation. They retain for two years a field-level audit of changes to most fields in the records. For example, there are normally 230,000 changes made per summer. Data entry will be much easier in the new system and there will be much more validation provided. SPUDS is an on-line transaction processing (OTP) system that may have 18 simultaneous users. The new SPUDS will provide a web-based interface for students.

Data content:
The College owns the degree audit database and the data. They need to provide access and cannot rely on getting access to other systems. A subset of the SPUDS data elements is redundant and the rest is unique to the system. The records contain a unique ID, degree, department, course description, course number, term key plus term and year fields, and flags for the requirements that the course meets. Note: course descriptions for the Course Listing are captured in a word processing format, not a database format.

SPUDS information flow:
The University Registrar is responsible for University-level not Department-level registration. They track students and status. If the Department approves the degree requirements for the major and the College approves the College requirements and the Bursar clears the student, then the student graduates. The University tracks courses and grades (content) while the Department and College track requirements (context). The Colleges collect grades from Departments and forward them to the University Registrar. The University Registrar enters the grades into the Student Records and Registration System (SRRS). The updated SRRS records are batched into the Student Information System (SIS). Transcript information is accessible from SIS. There is no front-end for users to SRRS.

SPUDS updates:
There are three possible scenarios for updating SPUDS records:

  1. Currently, student transcript data are updated over the summer for junior and seniors.
  2. Engineering updates all students every semester because the requirements are so tight for students.
  3. In Phase B of SPUDS development, there may be automatic updates, which would be the ideal.

Student Records data:
The SIS is on CornellC, the mainframe. The Student Records Data Mart is view of the SIS data for 1988-on. They extracted 10 years of data. A similar process could be used for 1981-1987 data. SIS uses procedural SAS on an underlying Adabas database that runs in the background. It is a CMS MVS environment.

Student Records Data Mart (SRDM):
Once a week, data for current students is pulled from SIS. The Official record is on the mainframe. The data is partitioned by year.

Mike recommends talking to Becky Tonz, who worked on the data warehouse; Scott Steiner, who works on SIS and wrote part of the extraction; and Robert Wilkinson, who has worked on the data in a variety of roles. Admissions and accounting data are also stored on the mainframe.

Admissions process:
The College of Arts and Sciences uses a VisualFox application called Folders to manage admissions. The Admissions Office has the UAO system on CornellC. The admissions process is paper-based process that captures documents in folders and puts them in boxes that are circulated. Folders captures basic biographical data, statistics on scores, Ids, etc. Folders tracks when the Folder was added, who has looked at it, a marketing code for dean, region, country level admissions benchmarks. International students are tracked separately. Statistical and other reports are issued daily. Folders tracks the process through acceptance. After the admissions process is completed, records for students who accept offers are moved into MARS, which matches students with advisors, arranges meetings and manages orientation. Then student records are moved to SPUDS. For Arts and Sciences 13300 apply, 3200 are accepted, and 1200 attend. There College currently has about 4400 students.

Future plans:
PeopleSoft may still be used for student records. According to the original plan, the degree audit module would be in place now. The plan slipped 5 years in two years. Within five years, Revelation will not run because Microsoft will support NT with no DOS. This is the reason for the 2 _ year deadline. PeopleSoft would have provided the degree audit module for all Colleges. Given the Revelation support deadline, Arts and Sciences cannot wait for PeopleSoft or whatever other option is selected. The new SPUDS will only be available to the Colleges who buy into the project. Arts and Sciences will take on most of the development costs. Though the Colleges will develop the new SPUDS individually once they receive the code, Mike expects the underlying data structures to remain constant.

Long-term access:
The University Registrar fulfills most transcript requests. Some special requests require information from the degree audit system, such as licenses for SEC, legal, medical, biomedical fields; State Department clearances; and the requirements of some other employers.  

Other interesting information:

Cornell selected Informix over Oracle and PeopleSoft over other packages. They have now selected Brio over BusinessObjects as a query tool, primarily because 40% of the University, in particular accounting, use Macs. Brio has Mac interfaces, but there may be a problem for Mac users.

Meeting 6: Joan M. Falkenberg Getman, Caroline Hecht, Patrick Graham, Academic Technology Center, CIT, 1 August 2000

David Yeh, University Registrar, mentioned the use of CourseInfo by faculty for source websites in the context of discussing the broader scope of student records. (See notes from July 26 meeting with David Yeh) In addition to transcripts, it may be necessary to provide course descriptions, syllabi, information about the faculty, etc. Licensing, certification, and patent renewal requests may require more context for and content of a student’s academic record than the traditional transcript provides. This information is increasingly available electronically, which allows for links between what were discrete collections of information and the presentation of a range of views of the information to meet user needs. The Registrar intends to be ‘a repository of data for faculties to do business’. The Academic Technology Center (ATC) supports a range of programs to support the use of technology by faculty and student. To capture student records for long-term access, the Archives needs to identify the records to be retained, the issues pertaining to the retention these records, and the owners and users of the information and processes. All of the participants in the creation, maintenance and use of components of student records should work together to meet short-term and long-term needs and requirements.

Purpose of the meeting:
The original purpose of the meeting was to find out more about the functionality of CourseInfo and the issues pertaining to the potential long-term retention of information stored in a CourseInfo database. The final report for this project will contain sections on general and institution-specific issues. This meeting was intended to address general preservation concerns by exploring Cornell’s experience with CourseInfo. ATC confirmed in email prior to the meeting that Cornell’s implementation of CourseInfo generates HTML-pages on the fly from information stored in a MySQL database. The focus of the discussion shifted from the structure and content of the CourseInfo database to a number of policy-related and other issues.

Issues raised in the meeting:

ATC’s websites:
The CourseInfo website that is maintained by the Academic Technology Center contains extensive information on the selection and use of CourseInfo, as well as the other services that are provided to students and faculty by the Center that will be useful in preparing the report. In addition, the Blackboard website, the developers of CourseInfo, contains information on the options available to institutions for implementing CourseInfo.

ATC reviewed seven products before selecting CourseInfo in 1997. There are approximately 700 courses in CourseInfo with 5,000-7,000 students participating as of July 2000.

Potential collaboration:
It would be useful for the Archives to undertake or participate in a study of course content and curricula materials, including course website use, at Cornell. The study could include:

The study should result in:

The Archives should promote and participate in initiatives that address the creation, maintenance and use of academic records, course content and curricula materials. The AACRAO has identified these materials for retention and relevant records management and archival associations confirm this assessment. The Archives should support the efforts of ATC in these areas.

Meeting 7: Barbara Skoblick, University Audit Office, 2 August 2000

Data warehouses:

IDs: Electronic Academic tools: Audit Trails: Audits: Audit Standards: Audit examples and reports:

Meeting 8: Christopher Cox and Tracey Thompson, Student records Data Mart, University Registrar’s Office, 2 August 2000


SRRS/SIS: Data Marts: Storage of older SIS data: Course information: Just the Facts: Enrollment: Deceased students: Diplomas: Next steps:

Meeting 9: David Yeh and Chris Cox, University Registrar, 4 August 2000

The majority of the meeting involved explaining the status of the meeting and reviewing the draft report outline.

In addition, the meeting included the following topics:

PeopleSoft student system:

Course descriptions and syllabi:
The discussion began with a review of the CourseInfo meeting.

Mandarin Project:
Springing from a reference to Cornell's role in the Mandarin Project, which began in 1990, the discussion allowed the Registrar to provide additional information.[Note: Mandarin is referenced in: Donald Gwinn and Louise Lonabocker (eds.). Breakthrough Systems: Student Access and Registration. Series: Technology in Higher Education Series. Washington, DC: AACRAO, 1996.]

Meeting 10: Graham Hall, Reporting Infrastructure, 4 August 2000

Graham Hall has been actively involved with most recent large project implementations at Cornell. He was active in Bear Access, PeopleSoft.

Mandarin Project:

PeopleSoft: Upgrades:

Meeting 11: CornellC backup procedures, Mike Garcia, 4 August, 3:30 pm

Backup and recovery procedures for SIS/SRRS on CornellC:

Tour of the computer center.

It would probably be worth doing a system audit of SIS/SRRS and a COM version, especially for 1981-1987, which are not accessed by the data mart.