. . CALIFORNIA STATE UNIVERSITY, NORTHRIDGE
ON-LINE UNDERGRADUATE ADVISEMENT
SYSTEM FOR COMPUTER SCIENCE FACULTY
A thesis submitted in partial satisfaction of the requirements for the degree of Master of Science in
Computer Science
by
Robert Oberwager
January, 1984 The Thesis of Robert Oberwager is approved:
Steven Stepanek
John Swanson
Morteza Anvari, Chair
California State University, Northridge
ii ACKNOWLEDGEMENT
This acknowledgement is to thank my committee members for their kindness, patience, under standing and assistance in getting the final product done.
iii TABLE OF CONTENTS
ACKNOWLEDGEMENT • • • • • • iii
LIST OF TABLES AND FIGURES vi
Chapter
1 INTRODUCTION AND BACKGROUND • 1
1.1 Introduction • • • • • • 1 1.2 Background • • • • 1
2 ANALYSIS OF PROBLEM 6
2.1 Review of Current Procedures 6 2.2 User Requirements • • • • • 10
2.2.1 User Demands of System • • • • • 10 2.2.2 System Usage • • • 11 2.2.3 Communication with Other Systems . • . • • • • • • • • • 11 2.2.4 User Technical Background and Training • • • • 12 2.2.5 Type of VDT Terminal and Speed to Use • • • • • • . . • . 12 2.2.6 Choice of Computer System for Implementation ••••• 13 2.2.7 Programming Language to be Used • • • • • • • • • • • 14 2.2.8 Expected User Load, Port Availability, and Reponse Time ...... 15 2.2.9 Access Limitations and Privacy Concerns • • • • • • 16 2.2.10 System Ownership and Operational Control • • • • • • 18 2.2.11 Software Support, Maintenance and On-Going Development • • • • 19
3 DESIGN SPECIFICATIONS • • • 22
3.1 Menu Driven Systems • • • • . • • • 22 3.2 Output Considerations • • • • • • . 23 3.3 Input Considerations • • . • . • 24
iv 3.4 F.ile Design ...... 25 3.4.1 Disk-Student-Master File . • • • 27 3.4.2 Course-Master-Disk File 30 3.4.3 Advise-Student-History File 31 3.4.4 Advise-student-Master File • 33 3.4.5 Advise-Course-Master File • • • 35 3.4.6 Advise-Department-Student File • 37 3.4.7 Advise-Department-Faculty File • 39 3.4.8 Advise-Transfer File • . 40 3.4.9 Advise-xschool-Code File •• 43 3.4.10 HEGIS-Major File •••••• 44 3.4.11 Advise-Department-Info File 44
3.5 Program Module Requirements Design • 50
3.5.1 Batch Modules • • • 50 3.5.2 Interactive Modules 72
3.6 Module Time Estimates 91
4 SUMMARY AND CONCLUSIONS • 95 4.1 Project History •••••• . . 95 4.2 New System Interfaces Required in the Future • • • • • • • • . • • 98 4.3 Implementation Suggestions ... 99 4.4 Enhancements • • . • • • 101 4.5 Conclusions ••••.••. 101
BIBLIOGRAPHY 104
APPENDICES
A DEPARTMENT INFORMATION 107
B. FILE STRUCTURES • • • • . 120
c. SAMPLE ADVISE-DEPARTMENT-INFO FILE 127
D. AMBASE SCREEN UPDATING INSTRUCTIONS 134
E. LISTING OF BASIC+2 SOURCE PROGRAM 139
F. LOGIC FLOW: BATCH MODULES 152
G. LOGIC FLOW: INTERACTIVE MODULES 161
H. STUDENT TO FACULTY LOAD BALANCING CONSIDERATIONS • • . • • • • 180
ADDENDUM 184
v LIST OF TABLES AND FIGURES
Table
1 School of Engineering and Computer Science Student Population Count • • • • • • • • • • 8
2 Estimated Task Hours to Complete System Batch Tasks • • • • • • • • 92
3 Estimated Hours to Complete System Interactive Tasks • • • • • • • • 94
Figure
1 SU04 Dump Tape Disk Reload Module 52
2 Creation of ADVISE-STUDENT-MASTER, ADVISE STUDENT-HISTORY, and ADVISE-COURSE-MASTER Files via AVOlOO and AV0101 Modules •••• 57
3 Creation of ADVISE-COURSE-MASTER File via AV0200 Module • • • • • • • • 59
4 Updating of ADVISE-DEPARTMENT File via AV0300 module • • • • • • • • 63
5 Archive/Recover of Department and Transfer Student Data via AV0400/AV0401 • • • • • 67
6 Comparison between ADVISE-STUDENT-MASTER versus ADVISE-DEPARTMENT-STUDENT Data Files via AV0500 • • • • • • • . • • 71
7 Faculty Advisor Menu Selection/Data Display Modules AV0125, AV0225, AV0325, AV04 2 5 • • • • • • • • • • • • • • • • • 76
8 Department File Maintenance Modules and Files Accessed Through AD0150 and Submodules • • • • • • • • • • • • • • • 82
vi ABSTRACT
ON-LINE UNDERGRADUATE ADVISEMENT
SYSTEM FOR COMPUTER SCIENCE FACULTY
by
Robert Oberwager
Master of Science in Computer Science
This thesis was undertaken with the objective of designing and implementing, on a limited basis, an on line undergraduate advising system for computer science
·faculty at California State University, Northridge.
Originally, the design and implementation was to be done using a database system. This system would be used to assist the faculty advisor and student in selecting the appropriate series of courses for the student to enroll in so graduation could be quickly achieved.
By placing student and department data in an on-line database, the advisor will be able to obtain accurate and timely information and eliminate a portion of the clerical work.
vii The contents of this document are divided into major sections on: 1) background information; 2) current department advising processes; 3) general system design requirement and specification factors; 4) specific file design; 5) specific software module functions: and 6) evaluation and conclusions.
Although part of the initial system design was coded and tested, the implementation was never completed.
This was due to the unanticipated loss of the AMBASE database software plus an increase in project size as more requirements were added to the system.
As a result, this project was redirected toward documenting a revised system design which conceptually could be implemented on the University's Control Data
Cyber 750 computer system. Hopefully this could be accomplished with the aid of an appropriate database package on the Cyber and the design material found within this document.
viii CHAPTER 1
INTRODUCTION AND BACKGROUND
1.1 Introduction
Faculty members, particularly in their roles as
student advisors, are inundated with university, depart
ment, and student record paperwork. Therefore, the goal
of this thesis is to attempt to improve the delivery of
advising information to the Computer Science faculty member. This goal can be achieved by implementing the
on-line undergraduate advisement system described in
this thesis.
Basic requirements for an on-line advisement
system were developed specifically for the Computer
Science department. After initial specifications were
formulated, implementation of one module was attempted.
Because the project encountered slowdowns, the project's goal was re-shaped towards the completion of the data
file and module designs for the advisement system.
1.2 Background
To be useful, advisement by computer must have accurate and up-to-date information in its database.
This is necessary to assure that appropriate academic choices are made when educational advising is done.
1 2
In addition, it is prudent to monitor the student's progress toward achieving his/her educational goals.
Computer-aided advisement will allow Computer Science faculty members to keep up with continually changing curricula and an expanding student population with diverse educational backgrounds.
Many faculty members use a university catalog, various lists of department requirements, transcripts and hand-tracking procedures to perform their advising tasks.
These items can be cumbersome to work with and can pre sent interpretation problems for faculty. This is true especially for faculty who are not interested in the complex but mundane advisement process, or for those faculty who must advise in fields outside of their edu cational and career experience background. Also, they usually are not provided with adequate advisement infor mation and training. In summary, faculty members can become dissatisfied in performing advisement tasks and students may not be given adequate guidance because of:
a. Shortage of time
b. Excessive number of students to advise
c. Lack of advisement materials
d. Lack of up-to-date and/or accurate materials
e. Inadequate training in procedures
f. Inadequate access to up-to-date student
records 3
g. Low incentive/interest due to repetitive,
bookkeeping character of the task
h. Ambiguous rules and requirements.
Some of these advisement problems may be allevi- ated by introducing the use of an on-line computer advising system. Such an implementation could reduce costs through savings in faculty member time.
An on-line computer advising system will provide: a list of courses necessary to meet requirements for graduation; student class/grade record history; course substitution (for example, for transfer student course equivalency credit); and examination results in certain areas of proficiencies. In Robert Spencer's (20) article on advisement by computing, he lists the following capabilities which may be provided.
1. Instant on-line and printing capability. 2. States and tracks all requirements for gradu ation. a. University b. General Education c. Major 3. Categorizes requirements within major. a. College b. Department c. Major d. Specialization 4. Capability to insert and track individually tailored and approved degree programs. 5. Capability to track number of classes, number of semester hours, and combinations. 6. Lists prerequisites for required courses. 7. Capability to show narrative information. 8. Includes all credit, substitutions, and waivers. a. Institutional credit b. Transfer credit 4
c. Miscellaneous credit (i.e., AP, CLEP, Military, etc.) d. Substitutions e. Waivers 9. Instant update capability. 10. Capability for students to "shop" for a major and review immed~ately change of major consequences. 11. Capability to change requirements as frequently as every semester, but track each student by date of entry into the major. 12. Provides management information. a. Course use by major and specialization b. Curriculum planning c. Total requirements for major 13. Capability to track two or more majors at the same time.
Spencer (20) believes that on-line computer assisted advisement can:
1. provide accurate degree requirement informa- tion for students and faculty 2. monitor and track student degree progress 3. free faculty from clerical responsibilities 4. provide support information for the profes sional evaluation and use by faculty 5. provide curriculum management information 6. eliminate fragmentation and duplication of effort 7. provide detailed graduation evaluation reports with no cost increase when compared to use of transcript and catalogs 8. use machines to do what they do best; free people to do what they do best 9. integrate related systems 10. provide flexibility to change and restate requirements.
Finally, Spencer (20) concludes that prior studies of computer assisted advisement have revealed: 1. A reduced amount of time is needed in evalu ating students for graduation 2. Improved accuracy in advisement occurs when faculty used academic advisement reports 3. Ease of obtaining information increases 4. Frequency of providing information can be increased 5. Cost reductions occur 5
6. Versatility of advisement allows for enhan cing and expediting.
As evident, advisement by computer can become a very helpful tool for the faculty advisor. A comprehen- sive advisement system implementation can be highly complex and difficult to manage. So it is necessary to be cautious when designing such a system so that it will actually provide a useful service. The system design described in this document is a first step in satisfying some of the Computer Science faculty members' desires for better advisement tools. CHAPTER 2
ANALYSIS OF PROBLEM
2.1 Review of Current Procedures
The Computer Science department faculty members spend a portion of their time performing administrative functions as well as purely instructional duties. One of these functions is advising students in their depart ment about courses they must take which will count toward completing their degree objective. The University Cata log describes the regular programs of courses a student normally undertakes, but various fields of concentrated studies and possible elective course selection present a myriad of potential choices. Also, if the student has transferred from another college (commonly one of the surrounding junior colleges), a translation of course equivalences must be done to determine the courses that can be accredited to the student. Normally, a CSUN
Departmental Evaluation--Computer Science form (see
Appendix A) is completed and signed by student, advisor and department chair.
Typically, students are assigned by the depart ment to a particular advisor. Students are advised during set time periods of approximately one to two
6 7
weeks each semester. During this period there are a
large number of students who seek guidance. Instructors
usually advise by appointment and have with them a
department-maintained student record folder for refer
ence. This folder contains all student degree-related
records, such as courses taken and grades received.
The faculty member then uses the student's file,
plus department and university curriculum requirements,
in order to advise the student. Because the manual main
tenance of student files must be accurate and done in a
timely fashion, and up-to-date department requirements
must be available, it was proposed that a "computerized"
information retrieval system would aid the faculty member
in helping students seeking guidance. This would allow
them to do their job faster and with more accuracy.
For the Fall semester of 1983, the School of
Engineering and Computer Science had a student population
count as shown in Table 1. These numbers could have been
higher but the program is impacted and a limit has been
placed on the number of students accepted into the pro gram. The total number of transfer students is rela
tively low (4.7 percent), perhaps also affected by pro gram impaction. The percentage may also be small due to
low tuition costs for California residents.
The Computer Science department has approximately
20 regular faculty members and about 30 part-time faculty members. Full-time faculty advise approximately one Table l
School of Engineering and Computer Science Student Population Count
Department of Department of Computer Science Engineering Total
Undergraduates 779 1,386 2,165 Graduates 164 354 518
Total 943 1,740 2,683
Undergraduate Transfer Students 31 50 81
Graduate Transfer Students 13 32 45
Total 34 82 126
There are also approximately 200 students minoring in Computer Science who are in need of advisement.
00
"" 9
thousand students in the major. There are about two hun dred Computer Science minors who also receive advisement.
Many transfer students complete their first two years of courses at a junior college and then transfer to California State University, Northridge (CSUN) as juniors. This would represent approximately 60 units of work or, at an average three units per course, 20 courses to transfer (these numbers will be needed for estimating data file sizes later).
Because undergraduate curricula, requirements, and advising processes are different from those of grad uate students, the system design is directed only toward the undergraduate student advisement processes. Addi tionally, the advisement database update processes were in some cases inplemented on a nominal basis. This is because there could be some students that, due to excep tions, could not be handled in a standard manner (for example, a student who had courses more than four years old). These exceptions would have to be handled on a case-by-case basis with the usual paperwork.
The standard complement of advising tools used by the faculty advisor in the Computer Science department are:
1. Transcripts
2. University catalog
3. Transfer course credit 10
4. Course correspondence with many junior
college courses
5. Department core requirements
6. Department concentrated studies
7. Course prerequisites and restrictions
8. List of old courses which have been renamed
and/or renumbered
9. Planned schedule of future course offerings.
Normally, the department assigns a student to an advisor. The student should make an appointment to meet
the advisor and discuss the student's needs.
2.2 User Requirements
The requirements of the expected users must be defined before the system specifications can be con structed. The following list of requirements partially follows that outlined in one of the projects from a CSUN course, Computer Science 480- Large System Design (6).
2.2.1 user Demands of System
The system must allow the faculty member to access accurate and timely information. Also, if some paperwork overload is eliminated, efficiency and produc tivity are increased. Faster, more accurate and effec tive advisement processes are the fundamental user oriented goals of the system. 11
2.2.2 System Usage
The primary user will be the faculty member
retrieving information from his video display terminal
(VDT) while the student is visiting his office for
advisement. In some cases, assuming a printer is also
available, there may be some need for hard copy reports.
Another user is the department secretary or clerk
who will have to assure that the databases are updated
in a timely fashion with revised department data. A
department member must also be responsible for the coor
dination and running of the overall system. For example,
certain master files will need to be updated at certain
times.
2.2.3 Communication with Other Systems
The two main interfaces required for this system
will be to the existing Student Master file and the
Course Master file currently maintained on the CDC Cyber
750 computer system. These files are maintained by CSUN
Admissions and Records. Due to the nature of the student data and privacy concerns, permission had to be obtained
to access these files.
Other interfaces to new software products which will be available in the future such as SIMS, CDPS, and
CARS (see section 4.2) will have to be investigated when more information becomes available. 12
2.2.4 User Technical Background and Training
Some faculty members are comfortable interfacing with a computer terminal and others are not. Those indi- victuals who have a technical background, especially in
Computer Science, will be at ease using good quality hardware and software products. Consequently, only minimal system training will be necessary for Computer
Science faculty. Department support personnel may require additional training, particularly in system maintenance operations. This is due to the fact the system maintenance functions are more complex than the faculty member's system interface and the use of a text editor will be necessary.
Although some users can easily learn and readily adapt to working with an information retrieval system, regardless of design, it is very important to make the system "user friendly" by operating with clarity, con- ciseness, and adequate help aids. This helps to ensure that regardless of what background the user has, or how little training has been provided, the system can still be easy to operate.
2.2.5 Which Type of VDT Terminal and Speed is to be Used
The Computer Science faculty members have Teleray lOT video display terminals available in their offices.
These terminals normally operate at a transmit/receive speed of 120 characters per second (1200 baud) as 13
currently connected to the University's computer equip- ment. The software to be designed for this system is to
be menu driven (see section 3.1) and would not need the
smooth-scroll features of such terminals as a VT-100 where the "jerkiness" of line movement is greatly
reduced. VT-100 terminals would also be supported
terminals as these are very ubiquitous devices.
The existing communication line speed of 1200
baud is minimally adequate and will perform satisfactor-
ily. However, a speed of 2400 baud would provide for higher user satisfaction with the system. This trans- mission speed increase will reduce menu display time,
thereby providing faster response time. Consequently, when equipment upgrades (and economics) permit, faster communication speeds should be implemented. This in-
eludes the caveat that the supporting main frame computer
is not so heavily loaded that it could not keep up with the data communication transmission rates if they were upgraded.
2.2.6 Choice of Computer System for Implementation
The University has two main types of computer hardware: a CDC Cyber 750 using the NOS 2.2 operating system and the DEC 11/70 using the RSTS/E operating sys- tern. The Computer Science department's DEC 11/45 using
UNIX was not considered a possible choice due to commit- ment to other needs and lack of sufficient capacity. The 14
DEC 11/70 was the machine originally selected because of
the relatively small set of data to process, and the
availability of a relatively good relational database
package, AMBASE (2,3,4,5). Although an extracted subset
of student data would have to be transferred to the
11/70 two or three times a semester, this should not be
a significant problem since data transfer takes place
so infrequently.
2.2.7 Programming Language to be Used
Some software development and database definitions were done using AMBASE on the 11/70. The University Com puter Center management subsequently decided to drop the
AMBASE system which then forced a halt to product devel opment. If possible, it is better to have all software and data together on one machine. Because of the AMBASE loss, it is suggested that the system implementation be done on the Cyber 750. Unfortunately, the University does not have a good relational database system on the
Cyber 750 that would have been as appropriate to use as was AMBASE.
BASIC+2 was the language of choice on the DEC
11/70 to complement AMBASE. On the Cyber the choice of language is dependent to some extent on the database system selected. COBOL is a possible programming lan guage to use as relevant CSUN data sources are being maintained by COBOL programs. INFOFETCH (see section 15
4.3) is a relational database system which generates
COBOL code and may be a database candidate if the vendor can provide an enhanced product and improved documentation.
2.2.8 Expected User Load, Port Availability, and Response Time
The possibility of more than two or three Com- puter Science faculty performing advising functions
(while using their VDT) at the same time would be low since faculty advising schedules are spread out over many hours. At CSUN, gaining access to the computer system is accomplished through a port selector. A restricted num- ber of ports are available and any further access re- quests will be denied if all ports are in use. Access requests, however, are queued up in a first-in first-out queue so that the user will ultimately get a port request filled. A faculty member must have very high port avail ability. If the instructor is with a student needing advisement (perhaps on appointment) he cannot wait very long to get a port. The information to advise the stu- dent is needed immediately. Adequate port access must be available even if it means the department has to pre- schedule faculty advising hours to permit this prompt access.
Not only do faculty members need to have fast port acquisition, they also need a fast response time for retrieving and displaying information they request 16
upon their screen. For example, ten-minute delays in
providing information would be undesirable and make the
system ineffective. Long delays will cause the advisor
and student to become frustrated. Response time for
retrieving department information should be no longer
than three to five seconds. Whereas, when retrieving
student record information, a response time of no more than 20 to 30 seconds would be reasonable.
Some compensation for slow response time is
possible if a printer is connected to the VDT. Once a
retrieval is made it can be printed so a duplicate re-
trieval would not have to made again.
Although inquiry response time is certainly a
function of system software design and implementation, poor response time can evolve simply from overloading a
system with too many users and/or too many large, inef-
ficient applications. Again, this problem is not con-
sidered within the bounds of this document but is germane
to the development of an efficient and effective system.
2.2.9 Access Limitations and Privacy Concerns
This system allows access to student information
such as courses completed and grades. This type of in-
formation is confidential; so there must be concerns about providing security to guarantee privacy. Thus, all files should be available only to the authorized system user. All files must be defined as private. On 17
the Cyber 750 system, security and privacy is enforced through an account number and password log-in identifier.
Additionally, passwords may be placed on file names.
Theoretically, one account for faculty advising may be set up and shared by all advising instructors. Each semester the account•s password could be changed by the departmental system administrator. By having only one account allowed to run the system, there is stronger operating system security (since file permits are not necessary) but less user accountability. For more accountability each faculty member who advises can be given a unique account number which allows access to the system. Additionally, a password would be needed to execute the advising software package.
A separate account will be needed for performing data maintenance functions by departmental support per sonnel. This account will have a unique password, and the initiation of system maintenance procedures will require entry of a second password.
It is assumed there would be no conflict of security or invasion of privacy (including legal restric tions) if the system were expanded to other University departments. One department could look at the records of a student within another department since advisement must be given to students who are within a mixed disci pline or are under a curriculum with a minor field of interest. However, should concerns arise, an additional 18
security module including a validation list could be de- signed and implemented so that only selected information could be retrieved. Also, when a new release of the
Cyber's operating system (NOS 2.2) is distributed, there will be potential for taking advantage of additional se- curity features (such as "shell" constraints which evalu- uate and determine the legitimacy of commands or security access levels and categories assigned to files. This may be useful if system implementation is done on the Cyber.
For the current design suggested in this docu- ment, no security/privacy constraints were included other than the usual password on account number and advising system startup procedure for both faculty and department maintenance modules.
Although the system is not designed to allow the advisor to alter any information (which would cause a concern for security), the advisor must be sure to keep both his log-on account/password and the system execution password confidential. Passwords should not be displayed upon the screen where they are easily seen but rather they should be entered while in a non-echo mode, if possible.
2.2.10 System Ownership and Operational Control
The software system defined within this document would be owned by the Computer Science department. Should it be desired to expand the facility to the School 19
of Engineering and Computer Science or make it available to the entire University, the ownership and operational support responsibilities would change accordingly. Each department would still be responsible for maintaining the department database files. New software would be required or modification to existing products made as each department has different requirements. For example,
CSQT (Computer Science Qualifying Test) scores would normally only be of interest to the Computer Science department.
Operational control would reside at the depart- mental level. As revisions to procedures become neces- sary, the department would assume ultimate responsibility for distribution of new information and procedures. An independent specialized service facility should not become necessary to operate the system. This will allow direct control of the system to be retained.
2.2.11 Software Support, Maintenance and On-Going Development
This system was conducted as a student project and as such would not be continuously supported by the author. Consequently, if this system were implemented, someone must have ongoing support responsibility to correct errors and install changes. Conceptually, a faculty member could be the maintenance coordinator.
Assistance could be obtained with other continuing stu- dents performing maintenance assignments. This approach, 20
however, can lead to fragmented software design that is not very compatible with existing modules and may yield inconsistent software operation.
When software design, writing, and implementation is done, it becomes very important to ensure that soft ware documentation is accurate and updated in a complete and timely fashion by whomever implements and/or makes changes. One way to support this software is by the department hiring a capable person to implement and document software revisions using a standard.
Another alternative would be to take the software and expand it for University-wide application and let the product be supported by a University support service area such as the campus Computer Center. The danger in doing this is the department cannot retain as much product control and the process of generalizing for University wide requirements can lead to inefficiencies and unwanted user (and software) complexities.
A significant portion of the cost of software products lies within the maintenance portion of its life cycle. It is important to develop software with tools that allow for fast, easy-to-use methods to make changes and expand product capabilities. The selection of an appropriate database system is of concern both in terms of its own capabilities and in how well that tool will be supported by its vendor (or responsible party) and 21 Q • by the management of the University or departmental programmer support groups.
Practical concern over how the system will be maintained and improved is a requirement consideration.
The selection of a database system to implement the system will force a maintenance process upon the system implementor. CHAPTER 3
DESIGN SPECIFICATIONS
General design specifications may be applied over
all software products produced. This will provide for a
uniformity in the interface between human and machine.
Many design features must reflect human factor consider
ations which will provide for a non-ambiguous, user
friendly, operation. A menu driven system must be a
required design specification.
3.1 Menu Driven System
The design of preference is an interactive system
that is completely menu driven and will allow the user to
select a function by entering in either a task identifi
cation number or alphanumeric code. In some cases one menu will call another menu in order to further subdivide
option lists until the desired task level is reached.
Hopefully, no more than a nesting of three menu levels will ever be needed. The user may experience problems with both the time required to retrieve and display all of the menus and the user can encounter a loss of positioning.
Of course, at some point other selection criteria
information will have to be entered besides menu selection
22 23
items. These may be things like student file number or
name.
A menu driven system is a preferable way of pre
senting user choices because it is easy for the user to
read a stable screen. This mode is better than one that
displays information in a scrolling manner. Also, after
information is displayed on the screen, the display will
not be replaced until the user enters a continue signal
like a Carriage Return. Additionally, the user only has
to enter a selection number to request an operation
instead of entering a lengthy amount of information.
3.2 Output Considerations
It is preferable to have all output displays
follow a similar if not identical pattern so the user
can expect to find information displayed in a consistent manner. Human factor considerations should encourage
the designer to display identical information in the
same approximate area of a report or display screen and
in a consistent format. For example, a student file
number should always have a hyphen between the first
three digits and the last four digits.
For hardcopy reports sent to the Computer Center's
central printers, a standardized format is preferred.
These reports should always have a descriptive title, date and time stamp, page count, program identification and record control count totals. 24
3.3 Input Considerations
The software designer must have concern for the human factors which relate to input design. In the previously-mentioned Computer Science 480 class project
(6}, some criteria were indicated for interactive screen design. Some of the suggested items have been altered and/or added to so that they meet the needs of the design requirements of this advising system. Particularly, the following items are desirable in interactive screen operation:
1. User input should always be prompted and the
prompt should always appear on the same line.
2. When possible, a default value should be pre
sented (usually after the prompt and within
<>symbols}. The user has a choice of either
accepting the default value or entering a new
value. Also, the default value may change
should the system state change.
3. When possible, all user input should be val
idated to insure correctness. For example,
an input item may be checked to ascertain
that it is of correct length, type--alpha
versus numeric, proper format, or within a
range of permitted values.
4. When an input item is unacceptable and must
be rejected, the user should be given an
accurate error message in a consistent format 25
and always at the same screen location.
5. user help must be provided at each input
request so that if the user enters a help
request, an appropriate message will be
displayed. Preferably, the reply should be
short, no more than one or two lines. The
help aid should always be displayed on the
same screen location and in a consistent
format. If a long reply is necessary, the
entire screen may be used. After the user
has read the reply the original menu and
prompt will be redisplayed. Using a full
screen help is not desirable at the first
level of a help request because of the text
and menu display times required. It is
recommended that all inputs have a one or two
line help reply at the first level assistance
request. Only if help is requested a second
time would the user get a more detailed reply.
In the advisement system discussed in this
document, most input items would probably
only require first level help.
3.4 File Design
The design of each of the system modules described in the following pages will often require information from several data files. The first topic to be addressed is a 26
description of the necessary data files. All input files are designed to reside on the Cyber 750 computer system. File design specification concentrates on con serving disk space by eliminating duplication of infor mation. However, the price paid is an increase in disk accesses and response time.
Although the system described within the document is basically structured around the functioning of the
Computer Science department and for undergraduate advi sing, there is the possibility of expansion to the entire
School of Engineering and Computer Science (or even more).
Therefore, when the file designs were constructed, the student database population was set at 2,500 students
(the approximate number of all students within the School of Engineering and Computer Science), rather than just the undergraduate population of the Computer Science department. If only the undergraduate Computer Science students are extracted for processing, the count would only be about 1,000 and estimated file size calculations dependent upon the number of students should be reduced accordingly.
The following file descriptions are defined with
COBOL type descriptions such that "9" represents a nu meric field, "X" an alphanumeric field, and values within parentheses represent the character count. 27
3.4.1 Disk-Student-Master File
The Disk-Student-Master file is the basic founda
tion of the students• historical records at California
State University, Northridge. The complete record description of this master file can be found in Appendix
B. Each record contains 600 characters and is stored in an indexed sequential file with the student's character
file number (FILE-NUMBER-N) as the primary key (low-to high). All types of miscellaneous information are found within this file such as address, date of birth, sex, basis of admission, and grade point average. For the purposes of the requirements for this undergraduate advisement system, the only fields of interest to be looked at and/or transferred to other files are:
1. FILE-NUMBER-N PIC 9(7)
This is the five-digit file number assigned to
the student by Admissions and Records upon
entrance to CSUN.
2. NAME PIC X(20)
This is the student's legal name.
3. MAJOR PIC X(S)
This is the HEGIS major code and is a five-digit
number representing a specific discipline that
the student is majoring in. For example, Compu
ter Science has a major (or HEGIS) code of 07011. 28
4. SUMMER-SESSION-1-DISC PIC X This is a flag that represents if Summer Session
I information has been put on this master record.
5. SUMMER-SESSION-2-DISC PIC X
This is a flag that represents if Summer Session
II information has been put on this master
record.
6. CLASS-YEAR PIC X
The value in this field will indicate whether the
student is an undergraduate or graduate student.
If the value is "1", "2", "3", or "4" it is an
undergraduate, a value over 4 indicates a grad
uate. The STUDENT-STANDING field would give a
finer breakdown but this is not necessary.
7. TICKET-GRADE-N OCCURS 15 TIMES
TICKET-N PIC 9(5)
GRADE PIC X
UNITS PIC 9V9 There are a maximum of 15 eight-character fields,
each of which contains the five-character course
ticket number, the one-character grade for the
course, and a two-character number of units for
the course. CSUN does not currently carry a plus
and minus sign on grades in the Disk-Student
Master file. If plus and minus are added, the
grade field should be expanded to two characters. 29
8. 2ND-MAJOR-N PIC 9(5)
This field can contain a five-digit number
representing a second HEGIS major code if the
student is in a double major.
The Disk-Student-Master file has four "leader" records at the beginning of it before the real student data starts. The first leader record is the Initial
Record and has a file number of "0000001" and a valid date.
Records two, three, and four are just dummy records and should be ignored.
Record five is the first valid student data record and will always have a file number greater than
5800000.
There is a Fall semester Disk-Student-Master tape and a Spring semester tape. The Spring semester tape also has Summer Session data included on it. After tapes are about six weeks old, they are sent to an off-campus site for protection. In order to process these older \ tapes, vault retrieval requests will have to be made. '
The Admission and Records Office at CSUN usually creates file updates on the zero, third, fourth, fifth, eighth and eleventh weeks of the semester. There usually
is continuous processing thereafter on an irregular schedule. Additionally, grades of Incomplete are not updated on this master file system and are only kept in
hard copy format. Because the Admissions Office 30
estimates that about four percent of the grades are
changed, it was decided not to be concerned with any
change of grade processing. However, change of grade
information can be easily kept in the Advise-Transfer
file (see section 3.4.8} if the department is willing
to enter the information through the department file maintenance modules (see section 3.5.2.2}.
3.4.2 Course-Master-Disk File
For every CSUN Disk-Student-Master file there is
a corresponding CSUN Course-Master-Disk file. This is
because the Disk-Student-Master only contains the five
digit ticket number for each course the student has
taken. If course title and other associated information
about the course is needed it must be processed concur
rently with the student records. The complete record description of this file can be found in Appendix B.
Each record description is 640 characters. It
should be noted that there are two class-records per
logical record. The file is sequential and in order by
the five-digit ticket number.
The fields of interest for the advisement system are (again, in COBOL nomenclature}:
1. CL-TICKET PIC 9(5}
This field is the five-digit class ticket number
that identifies the course and is the field upon
which the record order is based. 31
2. CL-DEPARTMENT PIC X(4)
This field contains the department identifier
that the course was offered under. For example,
COMP for Computer Science.
3. CL-COURSE-NUMBER PIC X(6)
This field contains the other part of the course
identifier that goes along with the CL-DEPARTMENT
information. For example, a value of 580 would
go with COMP (above) to represent a course,
COMP 580.
4. CL-TITLE PIC X(l7)
This field contains the actual title of the
course. For example, SOFTWARE ENGINEER would be
the course title.
5. CL-YEAR-AND-TERM PIC XXX
The first two characters represent the year and
the third character indicates the term the course
was offered. For example, 834 would represent
the two-digit year 83 and the Fall term.
3.4.3 Advise-Student-History File
This file will represent the working student history file after selected information from the Uni- versity's Disk-Student-Master has been transferred to this file. Note, because an advisement system must go back in time for several semesters or years, each of the
Disk-Student-Master tapes must be processed in order to 32
construct a full student history. The file created shall
be an index-sequential file with the primary key being
FILE-NUMBER-C (low-to-high), YEAR-TERM-C (high-to-low),
and COURSE-TICKET-NO-C (low-to-high).
1. FILE-NUMBER-C PIC X{7)
This is the student identifier assigned by CSUN.
2. YEAR-TERM-C PIC X(3)
This is the two-digit year followed by a one
digit term identifier. This represents the date
that the course was taken.
3. COURSE-TICKET-NO-C PIC X(5)
This is a unique identifying number assigned by
CSUN to a particular class for a given semester.
Together the YEAR-TERM-C and COURSE-TICKET-NO-C
fields form an index into the Advise-Course
Master file (see section 3.4.5) where the depart
ment and course title may be referenced.
4. COURSE-GRADE-C PIC X
This is the grade the student received. As in
Disk-Student-Master file (see section 3.4.1), one
additional character will need to be added if
CSUN begins recording plus and minus grade values. - i The record size will be 16 characters. If there are
approximately 2,500 students, and if an average student
has four classes per term by two terms per year for four
years of history, a disk storage requirement of about
1,280,000 characters (i.e., 16 x 2,500 x 4 x 2 x 4), or 33
about 2,000 physical resource units (1 PRU = 640 charac
ters on Cyber disk hardware) will be required.
3.4.4 Advise-Student-Master File
This file will represent another master file derived from the Disk-Student-Master file. It will be used during system operation in conjunction with the
Advise-Student-History file. This file is constructed at the same time that the Advise-Student-History file is built. This will be an index-sequential file with a primary key of FILE-NUMBER-M (low-to-high). Also, an alternate key should be constructed on NAME-M.
1. FILE-NUMBER-M PIC X(7)
This is student file number.
2. NAME-M PIC X(20)
This is student's name.
3. MAJOR-M PIC X(5)
This is the student's major HEGIS code.
4. MAJOR2-M PIC X(5)
This is the student's second major HEGIS code.
5. CURRENTLY-ENROLLED-M PIC X
This is a flag to indicate if the student is
enrolled for the current semester (Y = yes,
N =No).
The record size will be 38 characters and there will be approximately 2,500 student records. This will 34
yield a file size of approximately 95,000 characters
(i.e., 38 x 2,500) or 150 PRUs.
The Advise-Student-Master file and the Advise-History
Master file could be combined into one file. This file could have the Student-Master record as a fixed length header and the class transcript information portion could be appended on as a varying length set. This type of variable length record is supported in the Cyber 750 sys tem. If practical, these two files should be combined.
This may save some disk accesses when the file is used in production. Production modules AVOlOO and AVOlOl
(see section 3.5.1.2) could be modified to do this, or their output files could be merged by a third module.
Because the database system to be used for implemen tation has not yet been determined, there could be some impractical consequences of using a varying length file, particularly if the database system does not support this type of file structure. Additional complexities could arise by the possible formation of many-to-many relationships which may also be difficult to handle with some database systems (or components thereof such as report generators). Also, a two file structure may be better suited for performing certain database operations and performing miscellaneous ad hoc queries.
It may be wise to stay with a two-file structure unless it is demonstrated that benefits will be gained by switching to a one-file structure. 35
3.4.5 Advise-Course-Master File
This file will represent an extract of the Course
Master-Disk file. It will be built as the Course-Master
Disk files are processed for all those semesters of data that are wanted (and should match the same number of semesters data used to build the Advise-Student-Master file). This file is an index-sequential file with the primary key consisting of the fields YEAR-TERM-C (high to-low) and TICKET-NO-C (low-to-high). An alternate key should be constructed on YEAR-TERM-C (high-to-low),
COURSE-DEPARTMENT (low-to-high) and COURSE-NUMBER-C (low to-high) •
1. YEAR-TERM-C PIC X{3)
This is a two-digit year and one-digit semester
code.
2. TICKET-NO-C PIC X(5)
This is the course ticket number.
3. COURSE-DEPARTMENT-C PIC X(4)
This is the department identifier.
4. COURSE-NUMBER-C PIC X(6)
This is the accompanying part to the department
identifier.
5. COURSE-TITLE-C PIC X(l7)
This is the title of the course.
6. COURSE-UNITS-C PIC 9V9
Number of units assigned to course. 36
The record size will be 37 characters. There are almost 6,000 graduate and undergraduate courses offered per semester (excluding Summer Session) as indicated in the CSUN Schedule of Classes. Graduate courses could be eliminated from this database by checking if the course number is over 499, but there could possibly be some undergraduates enrolled in them. Therefore, it is pref erable to retain graduate level courses in the database.
Because of class section duplication (e.g., BUS
224 could have five sections offered) there are multiple duplicate class titles. If duplicate class titles are eliminated from the 6,000 courses, it is estimated that there are about 2,000 unique courses offered per sem ester (of these, about 80 percent are undergraduate).
Some disk savings could be generated if ticket numbers are not retained and department-class-numbers were used, as long as the number of students in the database is small. If larger student databases were to be processed the file design as presented here is preferable. With a record size of 37 characters, and assuming about 6,000 courses per semester and two semesters per year (again ignoring Summer Sessions), and a history of four years is wanted, there will be a disk requirement of
1,776,000 characters (37 x 6,000 x 2 x 4) or 2,800 PRUs. 37
3.4.6 Advise-Department-Student File
A separate file will be needed to hold student information local to the department. In the Computer
Science department, information is kept on students for items such as Computer Science Qualifying Test (CSOT), and the COBOL and FORTRAN proficiency tests. This file will be maintained by the department and they will make all changes, deletions, and additions of data. The file created shall be an index-sequential file with the pri mary key being the student FILE-NUMBER-D (low-to-high).
An alternate key of STUDENT-NAME-D (low-to-high) will also be needed.
1. FILE-NUMBER-D PIC X(7)
This is the student identifier assigned by CSUN.
2. STUDENT-NAME-D PIC X(20)
This is the name of the student. This is a
potential duplicate of name in the Advise-Student
Master file but it needs to exist in case there
is no record in the Advise-Student-Master because
it has not been updated yet (possibly due to a
student registering late).
3. FORTRAN-PROFICIENCY-D PIC X
This indicates by codes of "P" or "F" if the
student has passed or failed a FORTRAN proficiency
examination. 38
4. COBOL-PROFICIENCY-D PIC X
This indicates by codes of "P" or "F" if the
student has passed or failed a COBOL proficiency
examination.
5. CSQT-D PIC X
This indicates by codes of "P" or "F" if the
student has passed or failed the Computer Science
Qualifying Test. A code of "C" is used for a
conditional pass-fail score.
6. CSQT-YEAR-MONTH-D PIC X(4)
This indicates the two-digit year and one-digit
term that the CSQT was taken.
7. CSQT-SCORE PIC 9(3)
This is the score the student received on the
CSQT test (the sum of the optically scanned and
manually graded parts).
8. ADVISOR-IDCODE-D PIC 9(3)
This is a three-digit code which represents a
particular faculty advisor via the Advise
Department-Faculty file.
9. GENERAL-PURPOSE-D PIC X(3)
FLAGS-3-D REDEFINES GENERAL-PURPOSE-D
FLAG-A-D PIC X
FLAG-B-D PIC X FLAG-C-D PIC X
This field is a general-purpose field which may
be used by the department as a single three- 39
character field or as three one-character fields.
The department may use this field (or flags) as
they see a need. Possibly, these items may be
subsequently used for an ad hoc query via a
record selection criterion. The record size is
43 characters, and with approximately 2,500
students there will be a disk storage requirment
of approximately 108,000 characters (i.e., 43 x
2,500), or about 170 PRO's.
3.4.7 Advise-Department-Faculty File
This file will hold department information about the department's faculty regarding their advising role.
It is a small file and is maintained by the department.
They shall make all changes, deletions and additions.
The file created shall be an index-sequential file with the primary key being the instructor's identification code, IDCODE-F (low-to-high).
1. IDCODE-F PIC 9(3)
This is a three-digit faculty advisor identi
fication code assigned by the department.
2. INITIALS-F PIC X(3)
This is the initials of the faculty member who
is assigned to the above IDCODE-F value.
3. ADVISOR-NAME-F PIC X(20)
This is the name of the instructor (last name,
first, middle initial). 40 " .
4. NO-STUDENTS-ASSIGNED-F PIC 9(3)
This is the current number of students assigned
to the advisor.
5. AUTO-BALANCE-F PIC X
This is a flag that is used to indicate if manual
assigning of students ( "M" ) to the advisor or
automatic assigning of students with load balan
cing among other faculty with auto-balance set
on ("A"} is to be performed. See Appendix H for
more detailed on auto-balancing.
With approximately 20 full time Computer Science faculty in advisement roles, the size of this file is insignificant. The record size is 29 characters and at
20 records, disk storage requirements are about 530 characters or 1 PRU for data. As a matter of interest, index sequential files with such a small amount of data require additional storage for index data, and other items so this file would actually consume several PRU's.
3.4.8 Advise-Transfer File
This file is a list of courses for each student who transfers courses from another college and wants equiva lent CSUN course credit for them. The file is created and maintained by the department. The departmental staff member who maintains the student records would be responsible for entering course credit information into the database. This file would be index-sequential with 41
a FILE-NUMBER-T (low-to-high) and YEAR-TERM-T (high-to low) forming the key.
1. FILE-NUMBER-T 9(7)
This is the student's identification number
assigned by CSUN.
2. YEAR-TERM-T 9(3)
This is two-digit year and one-digit term date
when course equivalence was made.
3. CSUN-COURSE-DEPT-T X(4)
This is the CSUN core or concentrated studies
department name abbreviation (e.g., COMP).
4. CSUN-COURSE-NO-T X(6)
This is the CSUN core or concentrated studies
course number that accompanies the course
department field.
5. GRADE-T PIC X
This is the grade the student received for the
course. This field will have to be expanded to a
two-character field if the recording of plus and
minus grade values becomes desirable.
6. UNITS-T PIC 9V9
This is the number of units assigned to the
course.
7. XFER-COURSE-ID-T PIC X(6)
This is the course identification descriptor as
defined at the transfer school. 42
8. XFER-SCHOOL-CODE-T PIC 9(3)
This is a three-digit code representing a
particular school from which a course credit is
transferred. This school name versus numeric
code identification must be assigned by the
department. See the Advise-Xschool-Code file
description in section 3.4.9.
The record size is 32 characters. The esti
mated average number of transfer records per
student is 20. About 125 students out of 2,500
for all students in School of Engineering and
Computer Science transfer courses to CSUN (see
Table 1) so an approximate requirement of 80,000
characters (i.e., 32 x 20 x 125), or 125 PRU's
will be needed.
Note, the three-character XFER-SCHOOL-CODE-T
field is used so the actual school name would not
be included within the record in order to save
space. Also, the code can be validated against
a master file (Advise-Xschool-Code file). With
only about 125 students it would be desirable to
include the college abbreviation directly within
the record and omit the school-code file. The
design requires a code so disk space would be
conserved in case the system was expanded to
include many more transfer students. 43
Because grade changes are not updated on the
Course-Disk-Master file, the Advise-Transfer file
may be used to hold change of grade information.
All that needs to be done is to put a CSUN school
code in the XFER-SCHOOL-CODE-T field and leave
the XFER-COURSE-ID-T field blank.
3.4.9 Advise-Xschool-Code File This file contains a list of the colleges which students usually attend before transferring to CSUN. When they transfer to CSUN, the students usually have courses for which they can get equivalent CSUN class credit. The responsibility for defining the codes and college names within this file should be at the highest level (depart ment, school, university) where the list will meet all user needs. The file will be index-sequential and the primary key will be SCHOOL-CODE-X (low-to-high).
1. SCHOOL-CODE-X PIC X(3)
This is the school code used to identify the
school from which the student is transferring
records.
2. SCHOOL-ABBREV-X PIC X(8)
This is a short field to hold a meaningful alpha
numeric abbreviation of the school name.
3. SCHOOL-NAME-X PIC X(25)
This is a field to hold the complete school name. 44
The record is 36 characters and even at estima
ting a space for 100 school names, the disk requirements
will be approximately 3,600 characters, or 6 PRO's. A
very small file.
3.4.10 HEGIS-Major File
This is an existing CSUN file contained within a
set of files named COSAR, and it is supported by the
Chancellor's office. This file is used simply to verify
correct major codes and to retrieve the corresponding
name from a code-name correspondence.
The fields of interest for this file are:
MAJOR-CODE PIC 9{5)
LONG-NAME PIC X{l5)
SHORT-NAME PIC X{5)
This file would be used t? verify the major code
used to determine which student records to extract from the CSUN Disk-Student-Master file. Normally, only Com puter Science majors {and second-major students) will be used. However, if other majors were extracted, such as engineering, it would be appropriate to verify the codes.
Currently, this is a sequential file and contains less than 200 entries.
3.4.11 Advise-Department-Info Files
There is a need for two formats of general pur pose department information terminal display files. The file formats are used for sequential, but relatively 45
short, data files which can be maintained by a text
editor (such as the Full Screen Editor (FSE) that is
available on the Cyber 750 NOS 2.2 operating system).
These data files are simple 80 character (maximum) line
formatted text lines which contain departmental informa-
tion arranged in an 80 character by 20 line structure.
The remaining four lines (assuming a 24 line display
screen is used) are for user input and error messages.
The first file format is used for straight text
line displaying to the screen and the second file struc-
ture is for displaying a menu of selections which then
allows a choice of information to be displayed. Natur-
ally, any program modules using these files must be coded
to handle these file formats. One procedure would be pro-
grammed to display the file information. It could then be
used by any routine that can call it and pass the file
name to it. Each file would normally contain just one
category of material {such as CSUN course equivalencies).
3.4.11.1 Advise-Department-Info File Type 1
Comment lines are formed and denoted by an excla- mation point placed in columns one and two. These comment
lines may be placed anywhere within the file and will not
be displayed upon the user's screen. As a standard pro-
cedure, it is good practice to place at least two comment
lines for documentation purposes at the beginning of the
file. 46
Next, the file should contain five lines of header or title text and column identification fields if present.
The third and final component of the screen dis- play is a maximum of 15 data lines.
The five-line header will be retained on each subsequent screen so each group of 15 following lines
(excluding comment lines} will be displayed. At the end of each screen display the user is asked if he would like to continue displaying the text or return to the main menu. An example of one of these Type 1 files is found in Appendix c. To summarize, the file structure will look like the following sample:
File Line Columm Number 123 ••• Line Text
01 ll THIS IS SCREEN 1 COMMENT 02 !! THIS IS SCREEN 1 COMMENT 2 03 Blank line for formatting 04 THIS IS SCREEN HEADER LINE 2 05 06 THIS IS SCREEN HEADER LINE 4 07 08 THIS IS FIRST LINE OF SCREEN TEXT LINE 09
22 THIS IS 15TH AND LAST LINE OF SCREEN 1 23 ! ! 24 ! ! 15 MORE LINES OF SCREEN 2 TEXT CAN 25 ! ! FOLLOW 26 THIS IS FIRST LINE OF SCREEN 2 TEXT 27 AS MANY 15 LINE SCREEN GROUPINGS CAN 28 FOLLOW AS DESIRED 47 ,, .
The department-maintained files which use this
Type 1 structure are:
1. CSCORE describes undergraduate core pre requisite structure
2. CSEQUV describes CSUN course equivalency with other colleges (for example, Pierce and Valley junior colleges)
3. CSCOUR describes CSUN course equivalency between CSUN renumbered/renamed courses
4. CSMINR describes requirements for a minor in Computer Science
5. CSMAST describes graduate core prerequi site structure (although perhaps more appropriate to graduate stu dent advisement, it could be use ful for advising seniors planning to go on for a Masters degree)
6. CSGENE describes Computer Science and general education requirements
Samples of all of these files are found in Appen- dix C.
3.4.11.2 Advise-Department-Info File Type 2
Comment lines are formed and denoted by an excla- mation point placed in columns one and two. These com- ment lines may be placed anywhere within the file and will not be displayed upon the user's screen. As a
standard procedure, it is good practice to place at
least two comment lines for documentation purposes at the beginning of the file.
The purpose of this file structure (when used with a properly coded procedure) is to display a menu 48 v .
(screen #00) of selections plus a set of selection
subscreens containing display text relative to the user's possible choices.
The first non-comment line will be a menu zero
identifier line with the characters !##! in columns one
through four, zeroes in columns five and six, and the number of menu choices (and hence subscreens of informa
tion) that will follow in the file.
After the menu zero identifier line, 20 lines of menu text follow. These 20 lines will contain all of the selections possible as described by the screens that
follow in the file.
After the menu selection screen description lines comes a new screen break line which consists of !##! in columns one through four, and the menu selection (or screen identification number) number in columns five and six.
Next comes five lines of text header material for this selection. These header lines will be retained and displayed on each succeeding set of 15 screen lines of text found under this selection (i.e., this works like the Type 1 screen previously described).
After all lines of selection one comes the next screen breakline wiith the next menu selection text following.
Finally, at the very end of the file there should be a special end-of-file line consisting of a !##!99 in 49
columns one through six.
To summarize, the file structure will look like
the following sample:
File Line Column Number 123... Line Text
01 !! THIS IS COMMENT LINE 1 02 !! THIS IS COMMENT LINE 2 03 !##!0002 THIS IS MENU 00 IDENTIFIER LINE. IT INDICATES THERE ARE TWO SELEC TIONS 04 LINES 4 THROUGH 23 ARE 20 LINES OF TEXT USED FOR DISPLAYING SELECTION MENU AS USER DESIGNS
23 24 !! COMMENT LINE 25 !! SCREEN 01 FOLLOWS 26 !! COMMENT LINE 27 !##!01 THIS IS START OF SELECTION 1 SCREEN 26 LINES 26 THROUGH 30 ARE HEADER TEXT 27 LINES AND WILL BE RETAINED AND 28 REDISPLAYED ON SCREEN AT LINES 1-5 29 IF MORE THAN ONE SCREEN FULL OF 30 TEXT FOLLOWS 31 LINES 31 THROUGH 45 ARE FIRST 15 TEXT LINES DISPLAYED ON SCREEN
45 46 ! ! COMMENT LINE 47 LINES 47 THROUGH 50 ARE THREE MORE 48 TEXT LINES DISPLAYED ON SECOND 49 SCREEN STARTING ON LINE 6 OF 50 TERMINAL - SINCE HEADER IS KEPT ON TERMINAL LINES 1-5 51 ! ! 52 !##!02 THIS IS START OF SELECTION 2 SCREEN
!##!99 THIS IS VERY LAST LINE OF FILE.
An example of a Type 2 file is found in Appen- dix C. 50
The department-maintained file which uses this
Type 2 file structure is:
CSCONC describes the undergraduate con
centrated studies options and it
has a test screen selection list.
A sample of this file is found in Appendix C.
3.5 Program Module Requirements Design
The application software product set for the undergraduate advisement system consists of both batch and interactive modules. The design of these modules is conceived as being run on the Cyber 750 with a COBOL approach to design, although the implementation would be better served if most of these modules could be implemented through a comprehensive database system.
3.5.1 Batch Modules
Design of the batch modules is relatively straightforward. Jobs are set up so they can be inter actively submitted. Normally, jobs can be directly started by "getting" a procedure file containing NOS job control language (JCL) statements and then initiating that procedure. Usually this job will submit the actual job so it will run without the user being logged in.
Later, the user will get a printout to confirm the satisfactory completion of the job.
Before the user initiates the job, however, there may be a "control card" disk file that needs to be edited 51
with the Cyber's full screen editor, FSE, to set the
values of any appropriate parameters.
Alternatively, the submission of the batch, or
short interactive, jobs could be done via a selection menu written with a CSUN Computer Center developed menu
system, MENU-170 (21). This will allow jobs to be
selected and run while requiring minimal NOS job control
language usage from the operator.
The available batch jobs as seen through the main menu selection are:
3.5.1.1 Module SU04
Description
This is an existing CSUN procedure which will
take a student/course historical dump tape and reload
three files to disk. These files are:
1. Course-Master-Disk
2. Disk-Student-Master
3. Delete file (not used)
In order to extract all of the student historical
information needed, two dump tapes for each academic year will be needed. They must be retrieved from the off campus vault site and processed by module SU04 in order
to load the files back onto disk for further processing.
See Figure 1 for a module SU04 overview. 52
SU04 Process
File is not used
Figure 1
SU04 Dump Tape Disk Reload Module 53
3.5.1.2 Module AVOlOO and AV0101
Description
This module will create two files which are the
Advise-Student-History file and the Advise-Student
Master file.
Procedure Flow
First read the control "card" (which is really on disk). This card image contains the five-digit HEGIS major code(s) of those types of students who are to be extracted from the CSUN Disk-Student-Master file. Both the MAJOR and 2ND-MAJOR-N fields would be used for a code match. If this system were to be used University wide then no major codes would have to be input in order to control record extraction.
Additionally this card could have a one-character field which would determine when the record extraction process executes whether to extract undergraduates, graduates, or both. Since this project is for under graduates only, it will be assumed that only undergrad uates will be extracted from the Disk-Student-Master.
The procedure would test the CLASS-YEAR field and trans fer only those records with values less than five to the
Advise-Student-History file.
Pass 1 is the processing of the current semester's
Disk-Student-Master file by sequentially reading it, and as this is done, two records are built and written to files SCRATCH-FILE-I and SCRATCH-FILE-2. These two files 54 Q '
store information for building the Advise-Student-Master
and Advise-Student-History files. This is where a "Y"
(for Yes) is moved to the CURRENTLY-ENROLLED-M field of
the Advise-Student-Master file.
Pass 2 processes first prior semester's data.
Since some students may be on leave for one or two sem esters but still may be on campus requesting advising,
these students' records should be retained and made available. Therefore, the prior semester's Disk-Student
Master file is compared with both SCRATCH-FILE-! and
SCRATCH-FILE-2 (both should be synchronized). For any
student present on this prior file and not on SCRATCH
FILE-! and 2, the student's information from the prior
file will be merged with SCRATCH-FILE-! and 2 to give
SCRATCH-FILE-3 and the SCRATCH-FILE-4.
Pass 3 processes the second prior semester's data. The logic follows that for Pass 2 file processing.
The prior semester Disk-Student-Master is now passed against SCRATCH-FILE-3 and 4. For any students' records found on the Disk-Student-Master and not on SCRATCH-FILE-
3 and 4, the students' data is merged with SCRATCH-FILE-3 and 4, giving a temporary Advise-Student-History file and the permanent Advise-Student-Master file to be used for production operation.
Pass 4 processes the remainder of any earlier year's data. The module AV0101 uses the permanent Advise
Student-Master file from Pass 3 to form the index of all 55 0 .
students that will be found within the main database.
Its index corresponds to that of the temporary Advise
Student-History file. However, the remaining data files for any earlier semesters must now be processed to extract the needed remainder of the students' course history
(classes taken and grades received). Therefore, for each of the prior semester files yet to be processed, tran script records are inserted among the records of already existing students on the temporary Advise-Student-History file.
For each remaining semester's Student-Disk-Master file processed, transcript records for existing students
(as determined by who is on the Advise-Student-History file generated from Pass 3) are inserted until the last semester file desired is processed. This gives the final
Advise-Student-History file used for production operation.
See Appendix F for logic flow information.
Reports
Module AVOlOO produces a control total report which lists the following:
a. module name, date and time stamp of run.
b. major HEGIS code and name of department used
for extraction.
c. number of noncurrent students added from
Pass 2.
d. number of noncurrent students added from
Pass 3. 56
e. number of second majors.
f. number of freshmen.
g. number of sophomores.
h. number of juniors.
i. number of seniors.
j. number of graduates (normally= 0).
k. total number students on temporary Advise
Student-History file.
1. total number of students on Advise-Student Master file.
Module AV0101 produces a control total report which lists the following:
a. module name, date and time stamp of run.
b. data from initial record on semester Student
Disk-Master file. This is repeated for each
file read yielding a list of semester files
(by date) processed.
c. total number transcript records on final
Advise-Student-History file.
See Figure 2 for a module AV0100/AV0101 overview.
3.5.1.3 Module AV0200
Description This module takes the current and prior semes ter('s) Course-Master-Disk files and creates from them the Advise-Course-Master file. For every CSUN Disk
Student-Master there is a corresponding CSUN Course- 57
Pass 1 Pass 2 Pass 3 Prior Prior Current Semester Prior Disk Disk Semester Student Student Disk AVOlOO Master Master Student Control Current Master Totals Report Course Prior Prior Master Course Disk Master Disk
Scratch File 1 Scratch Pile 3 Advise Advise Advise Scratch File 2 Scratch File 4 Course Student Student Master History Master File File File ('J'eTporary) ('I'errporary) Pass 4 Remaining etc. Semester Student Disk Master Files Remaining Course Master Disk Files
Final Final Advise Advise Student Course History Master File Scratch File 5 File
Figure 2
Creation of ADVISE-STUDENT-MASTER, ADVISE-STUDENT-HISTORY, and ADVISE-COURSE-MASTER Files via AVOlOO and AVOlOl Modules 58
Master-Disk file so a student's grade may be related to
a particular course taken through course ticket number.
Hence, for every Disk-Student-Master used in modules
AVOlOO and AVOlOl, a corresponding Course-Master-Disk
file must be processed through the AV0200 module.
Module AV0200 reads each of the Course-Master
Disk files in most recent to oldest order and appends
each file's set of information to the created Advise
Course-Master file.
See Appendix F for logic flow information.
Procedure Flow
First read the current semester's Course-Master
Disk file plus all earlier semesters onto a work file and
then sort the records by year-term date (high-to-low) and
ticket number (low-to-high), creating an index-sequential
Advise-Course-Master file.
Report
Module AV0200 produces a control total report which lists the following:
a. module name, date and time stamp of run.
b. date from each semester's data file processed
so there will be a list of files processed by
date.
c. total number of records on Advise-Course
Master file output.
See Figure 3 for a module AV0200 overview. 59
current and Prior Semesters' Data
Course Master Disk Files
AV0200 AV0200 Sort Module Work
Advise Course Primary Key Master 1 Alternate Key
Figure 3
Creation of ADVISE-COURSE-MASTER File Via AV0200 Module 60
3.5.1.4 Module AV0300
Description
The Computer Science department gives examina tions to students for COBOL and FORTRAN proficiencies, and the Computer Science Qualifying proficiency tests
(CSQT). These tests are administered by using optically scanned answer sheets which are sent to the CSUN Coun seling and Testing Center. The sheets are scored on their NCS Opscan scanner and the results written on a magnetic tape.
This magnetic tape is input to module AV0300 so that the test scores and dates can be transferred to the
Advise-Department-Student file.
The CSQT test consists of two parts. One part is optically scanned. The other part is manually graded because the answers are not machine readable. After the machine-generated scores are processed and posted to the student's record in the Advise-Department-Student file, the manually-graded scores must be added to the stored optically-scanned scores. A pass or fail value may also be assigned once the total score is known.
The total score and the pass or fail value may be posted to the Advise-Department-Student file through module AD0450 (see section 3.5.2.2.4). This is a one student-at-a-time operation. If this process becomes too slow, an interactive department module could be created that would allow the manual scores to be entered, added 61 0 . to the optically-scanned score, and then a pass or fail value assigned to the student's record.
Procedure Flow
A control "card" is read to acquire the date of the test which is written to the student records, and to read a sort parameter (N = name, F = file number) which determines if generated reports will be in name or file number order.
The tape is read and the records are sorted into either name or file number order as determined by the parameter value.
The sorted records are then sequentially pro cessed against the Advise-Department-Student file match ing on file number. For each match the CSQT score and the parameter card test date is moved to the student's record. If no matching file number record is found in the Advise-Department-Student file, the tape record information is written out to an error report file for printing.
As the records are sequentially processed a print report file is generated which contains a list of the records processed.
See Appendix F for logic information.
Reports
Two reports are produced. The first report is the list of matched records that had information trans ferred to the Advise-Student-Master file. The control 62 totals on this report are: a. number of input records.
b. number of good record matches with informa
tion transferred. c. number of record rejects because of a non
existent master record. The second part is the error report which lists all unprocessed tape records. The control totals are:
a. number of input records.
b. number of record rejects. See Figure 4 for a module AV0300 overview.
3.5.1.5 Module AV0400
Description The Computer Science department maintains the
Advise-Department-Student file and the Advise-Transfer files {among others). As students graduate, go on leave, or disappear, their records will still remain within these files. Thus, there needs to be a way to houseclean old data by archiving it to magnetic tape. Also, it would be desirable to be able to recover data that had been put into these archive files should a student decide to come back after more than two semesters. The AV0400 module describes the process for archiving data from the
Advise-Department-Student and Advise-Transfer files to magnetic tape. AV0401 is the module for recovering pre viously existing data. 63
NCS Optical scanner
Control Card
Advise Department Sort Master Work Files
AV0300 Module
AV0300 AV0300 Error File Up Report date Report
Figure 4
Updating of ADVISE-DEPARTMENT-MASTER file Via.AV0300 Module 64
Procedure Flow
The Advise-Student-Master file represents all current students and those who were enrolled in either of the prior two semesters. The students could be on leave or have graduated but they are still on file.
Since the data on the Advise-Department-Student and Advise-Transfer stays until deleted and all records contain a student file number, AV0400 will compare rec ords (via file number) to determine which records to archive. Any record on the Advise-Department-Student file that has no corresponding record on the Advise
Student-Master should be deleted from the Advise-Student
Master and merged in proper sequence with the "old" archived department data tape from a prior archive run. This is then written out to the "new" department data archive tape. Correspondingly, any data on the
Advise-Transfer file that does not have a file number match on the Advise-Student-Master can be deleted from the Advise-Transfer file. This is done after the data is merged in proper sequence with the "old" archived transfer data from a prior archive run and written out to the "new" transfer data archive tape. Naturally, the new tape out will become the old tape in on the next archive run.
This run should be done just after a new creation of the Advise-Student-Master file and after all manual deletes to the Advise-Department-Student and Advise- 65
Transfer files are done. It may prove to be desirable to do this archiving process just once a year.
Additionally, any records on the Advise-Transfer file or on the old incoming archive tape should be deleted and not written out to the new archive tape if they are older than, for example, seven years {or what ever number the department choses). This age value can be a fixed value in the module or treated as a "control card" parameter. This age limit is used to houseclean the archive tape of any old data.
The same process applies to the department archive tape. However, as each department record is originally written to the archive tape, a date field
{current year, term) should be appended to it.
Because this job would require four tape drives, it may be desirable to use intermediate scratch disk files and copy to tape sequentially so fewer drives would be required at any one moment.
See Appendix F for logic flow information.
Reports
Two reports are produced and both are similar.
The reports list the complete records that have just been archived out to tape and print control totals which are:
a. number of records on old (input) tape.
b. number of records added to tape (archived). 66
c. number of records deleted from old tape due
to date limit.
d. number of records written to new (output)
tape.
e. number of records read on Advise-Student
Master file.
f. number of records read on Advise-Department
Student file. g. number of records deleted on Advise
Department-Student file.
h. humber of records read on Advise-Transfer
file.
i. number of records deleted on Advise-Transfer
file.
See Figure 5 for a module AV0400 overview.
3.5.1.6 Module AV0401
Description
This module is the counterpart of module AV0400 and is designed to restore those records from the archive tapes for a returning student who had data originally archived.
Procedure Flow As the student re-enrolls, the Advise-Student
Master file will again contain his records. If this student's file number is compared against the Advise
Department-Student file and the Advise-Transfer file for 67
Advise Advise Student Department Advise Master Student Transfer
AV0400 or t---"'!:>o! AV0401 Module
Old Department Old Transfer Tape Tape
New Department New Transfer Tape Tape AV0400/0l Department . pt
Figure 5
Archive/Recover of Department and Transfer Student Data Via AV0400/AV0401 68
a record match and none is found, there may be archived information that should be restored to the Advise
Department-Master and Advise-Transfer files. Hence, the
Department and Transfer archive tapes are searched for any existing records belonging to the student and, if found, are transferred back to the database files. As the data is transferred back, the data should be deleted from the tape requiring a tape update process to take place so a new department tape and a new transfer tape would be created.
A recovery run can be run as often as needed but it will only be useful if the Advise-Student-Master file has been updated to reflect a returning student.
As in module AV0400, the number of tape drives needed at one time can be reduced by the use of temporary disk files.
See Appendix F for logic flow information.
Reports
Also like module AV0400, two reports are produced and are very similar. The reports list the complete records that have just been reloaded from tape and print control totals which are:
a. number of records on old (input) file.
b. number of records deleted from tape.
c. number of records written to new (output)
tape. 69
d. number of records read on Advise-Student
Master file.
e. number of records read on Advise-Department
Student file.
f. number of records recovered to Advise
Department-Student file. g. number of records read on Advise-Transfer file
h. number of records recovered to Advise-Transfer
file.
See Figure 5 for module AV0401 overview.
3.5.1.7 Module AV0500
Description
This module provides for a comparison between the
Advise-Student-Master file and the Advise-Department
Student file. The comparison will produce two discre
pancy reports that list those students which are not
found on both files. This report can be used to see if
for some reason a student is missing from the Advise
Department-Student file. If a student is found to be missing from the Advise-Department file he could be added
into the database by using interactive module AD0450
(see section 3.5.2.2.4).
Procedure Flow
The Advise-Student-Master and the Advise
Department-Student files are both sequentially read by
student file number and a check for a match is made. A 70
record for those students found only on Advise-Student
Master is written out to the Student-Master discrepancy report (report 1) and correspondingly, a record found only on the Advise-Department-Student file is written out to the Department-Student discrepancy report (report 2).
See Appendix F for logic flow information.
Reports
Two discrepancy reports are produced as pre viously mentioned. The first report will be a list of the full student data records for any student found on the Advise-Student-Master file and not on the Advise
Department-Student file. The second report will do just the reverse and list the full student data records for any student found on the Advise-Department-Student file and not on the Advise-Student-Master file. Both reports will print control totals which are:
a. number of records read on the Advise-Student
Master file.
b. number of records used on the Advise
Department-Master file.
c. number of no-match data records on Advise
Student-Master file listed on report 1.
d. number of no-match data records on the
Advise-Department-Student file listed on
report 2.
See Figure 6 for module AVOSOO overview. 71
Advise Advise Student Department Master Master
AV0500 Module
2
Discrepancy Report 1
Figure 6
Comparison Between ADVISE-STUDENT-MASTER Versus ADVISE-DEPARTMENT-STUDENT Data Files 72
3.5.2 Interactive Modules
Appendix D contains a description of the opera tional features that were found to be very useful for the AMBASE screen operator and were found to be "user friendly". There are several software modules in this advisement system that are designed to be run from a video terminal in an interactive fashion. Most of these interactive modules will require the same (or a subset thereof) functions as indicated below.
1. print screen/reprint screen
2. accept input
3. validate input
4. display confirmation/informational mesages
5. display error messages
6. retrieve records from database and display
7. change records in database
8. delete records in database
9. add records to database
All of these functions were available through the screen generator software found in the AMBASE database system (2, 3, 4, 5) which was one of the significant reasons why it was chosen as the software product to implement the advisement system. When AMBASE had to be abandoned, there was no software database system avail able in CSUN's Cyber 750 software library.
Consequently, it is suggested that generalized interactive software foundations may have to be coded 73
from an elementary level so that routines may be shared.
By studying the documentation (4), a user's understanding of how AMBASE's screen driver processes function may speed the design on the Cyber 750 system. This will save a significant amount of time and effort. Another approach might be to continue the search for some outside source of existing software that had database screen driven software with adequate vendor support.
For this advisement system, there are to be two independent sets of selection/task-initiation menus.
One menu selection system is for the faculty advisor to use during his student consultations and the second menu system is to be run by an individual at the departmental level who is responsible for maintaining the system data files for up-to-date information.
The faculty advisor display module is described in the following pages and then a section on the depart ment modules will be discussed.
3.5.2.1 Interactive Faculty Advisor Module AF0125
Description
This module is the main menu driver for the faculty advisor to use and is responsible for letting the advisor select the display of information from department databases or from the student's historical records.
A menu will be displayed on the screen as shown below: 74 • '
COMPUTER SCIENCE ADVISEMENT SYSTEM
SEPTEMBER 3, 1983 12:43
SELECTION MENU
DO YOU WANT TO LOOK AT:
1) STUDENT'S RECORDS 2) COMPUTER SCIENCE BS CORE PREREQUISITE STRUCTURE 3) COMPUTER SCIENCE BS CONCENTRATED STUDIES 4) CSUN COURSE EQUIVALENCY WITH OTHER COLLEGE 5) CSUN COURSE EQUIVALENCY 6) COMPUTER SCIENCE MINOR REQUIREMENTS 7) COMPUTER SCIENCE GRAD CORE PREREQUISITE STRUCTURE 8) COMPUTER SCIENCE AND GENERAL EDUCATION REQUIREMENTS (UNITS) 9) EXIT PROGRAM
PLEASE ENTER SELECTION:
Sample submenus that are called by this menu are found in Appendix C (for example, the Advise-Info file constructs).
Procedure Flow
The faculty member starts the system by initia- ting a NOS procedure file which calls the menu system.
The first menu displayed is the main selection menu (menu number 1). The advisor is asked if he wants instructions and, if so, help text is displayed which explains the purpose of the system and the choices he has available to him. At that point he can exit or continue and enter one of the menu's selections. Validations are done on all items entered to assure appropriateness. If illegal values are entered, clear error messages are displayed. 75 Q '
This module was actually coded in BASIC+2 (see
Appendix E) and was tested for proper operation. Only the student data record retrieval portion was not checked out since that was to be an AMBASE data file and was not available. The Advise-Department-Info file - type 1 (as described in section 3.4.11.1) structure was used for holding all department data except that for Computer
Science BS concentrated studies which used an Advise
Department-Info file - type 2 structure. The Student
Records display consists of data combined from the
Advise-Student-Master file, Advise-Course-Master file,
Advise-Department-Student file, plus the Advise-Transfer file and Advise-Xschool-Code file if there is course transfer information present.
See Figure 7 for modules AF0125, AF0225, AF0325, and AF0425 overview. Also see Appendix G for logic flow information.
3.5.2.1.1 Module AF0225
Description
This module is initiated via module AF0125. It displays three general categories of student data. These are as follows:
1. Department-maintained data which comes from
the Advise-Department-Student and Advise
Faculty files. 76
ADVISE ;,nViSF. ADVISE ADVISE ADVISE S'l'UDENT CC:VR5E STUDENT DEPAHTV:ENT HISTORY MASTER Ml•STETI MASTER TRF·.~;S!'ER
(j
ADVIS£ AD'.'ISE FACULTY AF0225 XSCHOOL CO~JF..
AF032S A1'0125
FACUI.TY ADVISOR
CSCONC* AF0425
1_1~
CSCOHE* CSEQUV* C3COUR* CS~llNH* CSMAST* CSGENE*
*ADVISE-DEPARTMENT-INFO FILES Figure 7
Faculty Advisor Menu Selection/Data Display Modules AV0125, AV0225, AV0325, AV0425 77
2. System-maintained student course history data
from the Advise-Student-History and Advise
Course-Master files.
3. Department-maintained course transfer data
from the Advise-Transfer and Advise-Xschool
files.
The faculty member may enter either the student's file number or name (last name, first name, initial} in order to retrieve the information. A search by file number will be either successful or not successful. A search by name can possibly retrieve several student records sequentially. This is because partial key searches are allowed if the exact name spelling is not known. For example, SMITH P could be entered and first the records for SMITH PETER would be found and next those of SMITH PAUL.
The faculty member is asked whether or not the correct student has been found for each retrieval so that unwanted student records may be skipped and not displayed.
If the faculty member does not wish to review the data again, the system returns to module AF0125.
See Appendix G for logic flow information.
3.5.2.1.2 Module AF0325
Description
This module is initiated via module AF0125. It displays for the faculty member a selection submenu that 78
provides for reviewing department-maintained text files.
The text is kept in an Advise-Department-Info (Type 2) data file format. One example of this would be the Com puter Science concentrated studies data file.
If the user does not wish to review the text material again, the system returns to module AF0125.
See Appendix G for logic flow information.
3.5.2.1.3 Module AF0425
Description
This module is initiated via module AF0125. It displays for the faculty member a selected department maintained text file. This text is kept in an Advise
Department-Inf6 (Type 1) data file format. One example of this would be the Computer Science course equivalency with other colleges' data file.
If the user does not wish to review the text material again, the system returns to module AF0125.
See Appendix G for logic flow information.
3.5.2.2 Interactive Department Maintenance Modules
The department must maintain the data files which they control. The following section describes modules which will allow the department to perform all tasks needed for database file maintenance. 79
3.5.2.2.1 Module AD0150
Description
This module will display for the department's
support personnel a main selection menu which may be used
to invoke maintenance functions on various department
files.
A menu will be displayed on the screen as shown
below:
COMPUTER SCIENCE DEPARTMENT FILE MAINTENANCE MENU SEPTEMBER 3, 1983 12:44
SELECTION MENU
DO YOU WANT
1) TRANSFER COURSE MASTER MAINT 2) ADVISOR MASTER MAINT 3) STUDENT MASTER MAINT 4) TRANSFER SCHOOL CODES MAINT 5) PRINT UTILITY 6) EXIT PROGRAM
PLEASE ENTER SELECTION:
Procedure Flow
When the user responds with a valid selection,
the chosen module is started and displays a secondary
screen that will request more input from the user. The
five needed modules are described in detail later but
are briefly identified here as:
Menu Item 1
AD0250 module will allow the user to add, delete, or
modify records in the Advise-Transfer file which contains data regarding the courses transferred 80
to CSUN for credit, and if the department
desires, CSUN change of grade.
Menu Item 2
AD0350 module will allow the user to add, delete or
modify records in the Advise-Department-Faculty
file (and the Advise-Department-Student file
since the assigned advisor's identification code
is carried in the student's record).
Menu Item 3
AD0450 module will allow the user to add, delete, or
modify records in the Advise-Department-Student
file.
Menu Item 4
AD055D module will allow the user to add, delete or
modify records in the Advise-Xschool-Code file
which is used for associating the student's
transfer course credit in the Advise-Transfer
file with the proper school.
Menu Item 5
AD0650 module is a general utility that will allow the
user to print various data file reports. Depend
ing upon the file, the output may either be
listed on the local printer connected to the
departmental operator's terminal (if present) or
the print file may be routed to the Cyber's high
speed printer. 81 " .
See Figure 8 for a module AD0150 and submodule overview.
3.5.2.2.2 Module AD0250
Description This module will allow the department's support personnel interactively modify the Advise-Transfer file which contains courses taken by a student at another college and approved for transfer credit at CSUN. This module can also be used to store and manipulate CSUN change of grade information if desired. A menu will be displayed on the screen as shown below. The data can be entered after each prompt.
FUNCTION (Change, Add, Delete, Retrieve)
1) FILE NUMBER --- 2) YEAR TERM 3) CSUN DEPARTMENT 4) CSUN COURSE NO 5) GRADE 6) UNITS 7) TRANSFER COURSE ID 8) SCHOOL CODE
Procedure Flow
The user selects the function desired by entering either a C, D, A, or R to correspondingly change an existing record, delete an existing record, add a new record, or retrieve and display an existing record.
The user can then enter the appropriate informa- tion as determined by the mode of operation. Screen oper- ation, as previously mentioned, can be designed to operate similar to AMBASE screens as described in Appendix D. 82
Q .
AD0150 Department Clerk
J\00250 Advise Transfer
Advise Department Faculty AD030>U
Advise Department Student
AD0450 Advise Department Student
JI.DOS50 Advise Xschool Code
Advise Department Faculty
Advise Department Student
AD0650 Advise Transfer
Advise Xschool Code Miscellan- eo us Reports
~- Advise DepartmQnt __.--··"" Info (Types 1 & 2)
Figure 8
Department File Maintenance Modules and Files Accessed Through AD0150 and Submodules 83
3.5.2.2.3 Module AD0350
Description
This module will allow the department clerk to interactively change the file of advisors. This may need to be done if new faculty are added or existing faculty deleted. Faculty name and initials could also change should they get married or otherwise change their names.
This module will modify the contents of the Advise-
Faculty file as a primary function but there is a sec- ondary impact affecting the Advise-Department-Student file since each student has an assigned advisor code which represents his advisor. The number of students that each faculty member is assigned to advise is also kept in the data record.
A menu is displayed on the screen as shown below.
The data can be entered after each prompt.
FUNCTION (Change, Add, Delete, Retrieve)
1) FACULTY ID 2) INITIALS 3) NAME 4) NUMBER STUDENTS 5) AUTO BALANCE
Procedure Flow
The user selects the function desired by entering either a C, D, A, or R to correspondingly change or de- lete an existing record, add a new record, or retrieve and display an existing record. To add a new faculty member, specify an identification code (if already used 84
the operator will be notified), his name (last name, first name, initial). A zero is entered into the Number
Students field upon creation of the record, but this field will automatically be updated to count the number of students assigned to the advisor. The Auto Balance field should be set to "M" if students are to be assigned to advisors on an individual basis. If an automatic re assignment of students is to be done to balance the load when advisors are added or deleted from the list, the
Auto Balance field should be set to "A".
When a new advisor is added to the list with Auto
Balance set to "A", a portion of those students will be taken from every other advisor who also has Auto Balance set to "A" so that an approximately equal number of stu dents is assigned to each "auto-balanced" advisor. Since some students may in effect be assigned new advisors, the student's advisor code must be changed in the Advise
Department-Student file. If the department does not want to move many students to maintain advising continuity, the auto-balance feature should not be used and instead only manual reassigment done.
When an advisor is to be deleted from the Advise
Faculty file, the Number of Students field must be zero so it can be assured no students are assigned to him.
If the number is not zero, the user will be asked if he wants to automatically reassign all those students to another advisor and, if so, which one. If specific 85
reassignment is requested, it will be done by changing all old advisor codes to the new one in the Advise-
Department-Student file. If specific reassignment is not requested, the user will be asked if the students should be transferred to other "autobalanced" advisors thereby evenly distributing the students. If none of these reassignment operations is requested, the faculty record cannot be deleted. See Appendix H for additional information on autobalance concepts.
The Faculty ID field is changed to another number (in effect deleting andre-adding the record), all records in the Advise-Department-Master field with the old number must be changed to the new one.
3.5.2.2.4 Module AD0450
Description
This module will allow the user to add, delete, modify or display records in the Advise-Department-
Student file. Normally each student record is controlled by the department's support personnel and may have its information altered as necessary.
A menu will be displayed on the screen as shown below. The data can be entered after each prompt.
FUNCTION (Change, Add, Delete, Retrieve)_
1 ) FILE NUMBER 2) NAME 3) FORTRAN-PROF 4) COBOL PROF 5) CSQT 86
6) CSQT- YR MO 7) CSQT-SCORE 8) ADVISOR ID 9) GENERAL
Procedure Flow
The user selects the function desired by entering either a C, D, A, or R to correspondingly change an existing record, delete an existing record, add a new
record, or retrieve and display an existing record.
The user can then enter the appropriate informa- tion as determined by the mode of operation. Screen operation can be designed to operate similar to AMBASE screens as described in Appendix D.
3.5.2.2.5 Module AD0550
Description
This module will allow the user to add, delete, or modify records in the Advise-Xschool-Code file which
is used for associating the student's transfer course credit in the Advise-Transfer file with the proper school. A menu will be displayed on the screen as shown below. The data can be entered after each prompt.
FUNCTION (Change, Add, Delete, Retrieve)
1) SCHOOL CODE 2) SCHOOL ABBREV 3) SCHOOL NAME 87
Procedure Flow
The user selects the function desired by enter
ing either a C, D, A, or R to correspondingly change an
existing record, delete an existing record, add a new
record, or retrieve and display an existing record.
The user can then enter the appropriate informa
tion as determined by the mode of operation. Screen
operation can be designed to operate similar to AMBASE
screens as described in Appendix D.
The operator should not delete or change school codes because of any course equivalencies existing in
the Advise-Transfer data file. Once a code has been assigned to a school it is best only to correct spelling
errors in the School Name and Abbreviation fields.
Another critical reason for not changing codes is for ongoing compatibility with the transfer course data archived with modules AV0400 and AV0401.
3.5.2.2.6 Module AD0650
Description
This module will allow the user to print various data file reports. Depending upon the file, the output may either be listed on the local printer connected to the department operator's terminal (if present), or the print file may be routed to the Cyber's high-speed printer. 88
A menu will be displayed on the screen as shown
below.
COMPUTER SCIENCE DEPARTMENT PRINT UTILITY MENU SEPTEMBER 3, 1983 12:52
SELECTION MENU
1) LIST OF ALL ADVISORS 2) FILE NUMBER ORDER LIST OF STUDENTS BY ADVISOR (ENTER ADVISOR'S CODE, INITIALS, OR ALL) 3) NAME ORDER LIST OF STUDENTS BY ADVISOR (ENTER ADVISOR'S CODE, INITIALS, OR ALL) 4) FILE NUMBER ORDER LIST OF ALL STUDENTS IN DEPT DATABASE 5) NAME ORDER LIST OF ALL STUDENTS IN DEPT DATABASE 6) LIST OF ALL DATA COURSE TRANSFER FILE 7) LIST SCHOOL CODE/NAME DATA FILE 8) LIST DEPARTMENT INFO TEXT FILE (ENTER ALL OR 1) 9) EXIT
PLEASE ENTER SELECTION? PLEASE ENTER SELECTION CRITERIA? DO YOU WANT TO ROUTE FILE TO REMOTE PRINTER
Procedure Flow The menu is displayed and the operator is first asked to enter a selection number. A choice of one
through nine is permitted. Choices one through eight will call submodules within AD0650 that will possibly ask for more user input and then ask if the output file should be sent to the remote printer (if no, output will
be listed on screen and local printer, if connected).
Selecting option 1 will take all information in
the Advise-Faculty file and format it to the print file.
It will then be printed at either local or remote printer 89
depending on user's choice. The listing will be in advisor code order. This is a very small file.
Selecting option 2 will take the students in the
Advise-Department-Student file and list in file number order by user selection of either:
1. list of all students' data if ALL was entered
2. list of all students assigned to particular
faculty advisor (Note, if an advisor's ini
tials or code is unknown, "/H" may be entered
to obtain a list of advisor names, initials,
and codes.
Selecting option 3 will take the students in the
Advise-Department-Student file and list in name order by user selection, again advisor help information may be obtained by entering "/H":
1. list of all students data if ALL was entered.
2. list of all students assigned to particular
faculty advisor.
Selecting option 4 will produce a list of all students' data in the Advise-Department database in file number order. This is done by taking all of the students' data from several files and combining them into one rec ord. The record is then sorted, formatted, and printed.
Selecting option 5 will produce a list of all students' data in the Advise-Department database in name order. Except for sort order, this option will operate the same as option 4. 90
Selecting option 6 will list all data in the
Advise-Transfer file in file number order. The Advise-
Student-Master file will be used to supply the student name. This will likely be a low usage option, since the list would normally be just for mass file reviewing.
Selecting option 7 will list all the school codes/names contained in the Advise-Xschool-Code file.
This is a very small file.
Selecting option 8 will list the department text files, Advise-Department-Info type 1 and 2 (see Appendix
C). If ALL is specified, all of these department files will be listed, else, the operator is prompted with a subdisplay providing a list of department type 1 and 2 files that are available for listing.
This submenu appears as follows:
COMPUTER SCIENCE PRINT TEXT FILE SUBMENU
WHICH DEPT INFO FILE WOULD YOU LIKE TO DISPLAY?
1) CORE REQUIREMENTS 2) CSUN COURSE EQUIVALENTS 3) OTHER COLLEGE COURSE EQUIVALENCIES 4) MINOR IN COMP SCIENCE 5) COMP SCIENCE AND GEN ED REQMTS 6) GRADUATE CORE PREREQUISITES 7) CONCENTRATED STUDIES
PLEASE ENTER SELECTION
To get a listing simply requires the user to select the text file of choice by entering the item number.
Reports
All reports produced by the print module AD0650 91
shall have control totals consisting of the number of records read from each file used plus a count of the number of records meeting any selection criteria constraints.
3.6 Module Time Estimates
Table 2 represents an estimate of the time it would take to implement the batch modules if they were processed by a skilled programmer/analyst. Time esti mates are for the final program logic designs, coding in possibly COBOL, testing, debugging, setting up production job control language, and writing programmer maintenance documentation and user documentation. These estimates are probably conservative.
Table 3 represents estimates for the same items, except they are for the interactive modules described in earlier sections of this document.
Total time from both tables add up to 942 hours.
Sufficient time after implementation should also be allowed to survey users and collect feedback so neces sary corrections and enhancements can be made to insure user satisfaction.
Additional time savings (or increases) may occur if a database system is used as an implementation tool.
The quantity of the database system will have significant impact on capabilities and implementation time. Table 2
Estimated Task Hours to Complete System Batch Tasks
Estimated Task Hours to Complete --~-~
Module Final Test Job Cntrl Document Document Total ID Description Design Code Design Language Progrmr User
SU04 Load dump tapes N/A N/A N/A l 2 2 5 to disk
AVOlOO Process first 3 12 32 4 2 10 10 70 Disk-Student- Master files
AVOlOl Process rest of 8 24 4 3 8 8 55 Disk-Student- Master files
AV0200 Extracts, sorts, 4 8 2 l 4 4 23 and builds Advise-Course- Master file
AV0300 Transfer COBOL, 4 8 2 l 4 4 23 FORTRAN and CSQT scores to Advise- Department- Student file
\.0 IV Table 2 (continued)
Estimated Task Hours to Complete System Batch Tasks
Estimated Task Hours to Com2lete
Module Final Test Job Cntrl Document Document Total ID Descri2tion Design Code Design Language Progrmr User
AV0400 Archive data from 12 32 4 2 10 10 70 Advise-Department- Student and Advise- Transfer files
AV0401 Restore data to 12 32 4 2 10 10 70 Advise-Department- Student and Advise- Transfer files
AVOSOO Compare Advise- 24 50 8 2 20 24 128 Student-Master versus Advise- Department-Student file, optionally update Advise- Department- Student file
TOTALS 76 186 28 14 68 72 444
1.0 w Table 3
Estimated Task Hours to Complete System Interactive Tasks
Estimated Task Hours to Com2lete
Module Final Test Job Cntrl Document Document Total ID Description Design Code Design Language Progrmr User
AD0150 Main Department 8 16 2 1 8 8 43 menu driver
AD0250 Update Advise- 8 20 3 1 8 8 48 Transfer file
AD0350 Update Advise- 20 40 6 2 12 16 96 Department-Faculty file (and Ad vise- Student-Master indirectly)
AD0450 Update Advise- 8 16 4 1 8 8 45 Student-Master file
AD0550 Update Advise- 4 8 2 1 4 4 23 Xschool-Code file
AD0650 Print request of 20 40 6 4 12 16 98 selected data
AF0125 Faculty-Advisement & 30 60 6 3 16 20 135 Inc AF0225, 325, 425
TOTALS 98 200 29 13 68 80 488
1..0 ,j::o. CHAPTER 4
SUMMARY AND CONCLUSIONS
4.1 Project History
The intent of this document was to present results of the research and design effort directed toward developing an on-line undergraduate advisement system for the Computer Science department. A proposal was made which provides for the creation of a limited databas~ information retrieval system to assist faculty members in their advisement of undergraduate students.
After the collection and evaluation of the basic system requirements and specifications, the first system module with user menu selection processes and department curricula information displays was programmed. Data were entered into the files and operational testing was com pleted. This part of the system was coded in the BASIC+2 language on the University's DEC 11/70 computer system.
Initially, the DEC 11/70 was selected as the computer of choice. The AMBASE (2, 3, 4, 5) database system was selected (along with BASIC+2 code where necessary) as the software package that would allow for relational data file constructs.
95 96 @ •
The DEC 11/70 was selected as the equipment to use because the University's only other computer hardware available, the Cyber 750, did not have an appropriate database system as was AMBASE. The Cyber's primary, vendor-supported, database system, DMS-170 (Data Manage ment System) (7-15), was overly complex for what was required. It did not provide the type of "user friend liness" with menu control screens and screen formatting capabilities that were desirable for this operation.
One reason in support of the Cyber 750 was that student grade and course data are currently processed on it. This processing is done with COBOL programs.
However, since the faculty advising database information would have to be transferred only once or twice a semes ter from the Cyber to the DEC, this did not seem to be a substantive reason for not using the DEC computer. Plus the files are mostly small subsets of the primary Uni versity data files.
Unfortunately, as work with the AMBASE database system was proceeding, a decision was made by staff of the University Computer Center to abandon the AMBASE software package. Because of the anticipated loss of this software package, work had to be discarded that was set up to use this system. This forced an investigation into other software alternatives, but none were really available on the DEC 11/70 as provided by the University Computer Center. Another alternative, if justification 97
could be made, would be for the Computer Science depart
ment to obtain its own administrative DEC 11/70 computer
system. Then software support decisions would be under
its control.
The author had in-depth familiarity with the
AMBASE database system and was aware of its capabilities
and had expected this knowledge to reduce "learning curve"
time and help in a speedy implementation. Since other
software product alternatives would have to be considered,
the project's completion time would increase.
Another factor which led to a significant in crease in project size was the growth in the system
requirements definition as investigation and exploration of user needs were undertaken. The needed number of
tasks had increased to the point where it would have been impractical to expect a fully implemented, tested, documented, and operational system to be delivered.
Tables 2 and 3 provide total time estimates of over 900 hours to implement all tasks.
Consequently, the goal of operational implemen tation was not achieved. Instead, this thesis discusses and presents the requirement considerations relevant to and the design of a system that could accomplish the basic functions.
It is intended that this document provide a foundation for another researcher to take the information presented and construct the actual software using an 98
appropriate database system (if one becomes available on the Cyber 750 computer system).
4.2 New System Interfaces Required in Future
The University is running a relatively new soft ware system called Student Information Management System
(SIMS). Currently, this system supports admission data but will soon support historical student record data.
This should be the same type of data as is currently maintained on the Admissions and Records Student master file-and Course master files. When the SIMS record mod ule is installed, these existing data files will be replaced with those of the new system. Consequently, if any software is developed around the existing data files, some additional interfacing will be required if and when the SIMS record module is installed. Projected installation of the SIMS record module is Fall of 1985.
There are two other Chancellor's Office systems soon to be implemented on the CSUN campus. One of these systems is the Computer Assisted Registration System
(CARS). CARS is tentatively scheduled for testing in the Summer of 1984 with full implementation in the Fall of 1984.
The other system developed by the Chancellor's
Office is the Curriculum Data Processing System (COPS).
Parts of COPS are already implemented at CSUN. This system aids in curriculum development and interfaces 99
with the Schedule of Classes development cycle. Addi tionally, the University is in the process of computer izing the development process for the Schedule of Classes by departments.
The University will be installing these products in the next year or two. It would seem advisable to con sider waiting until these products are operational at
CSUN and then attempt to implement an advisement system that can take full advantage of the new system's capabil ities and data formats.
Because of the significant need for adequate student advisement by all departments, it may be appro priate to initiate, through the Chancellor's Office, the development of a generic advisement system, with the capability of being modified to meet individual depart ment requirements, for both undergraduate and graduate students. The advisement system could and would inter face with many of these other systems.
4.3 Implementation Suggestions
The processing modules and the relevant data files have been described. If an implementation plan is to be put into effect, a major decision that has to be made is with what software tools it should be accom plished. Because the existing data files are on the
Cyber 750 and were done in COBOL, continued use of COBOL 100
to perform some data manipulation, like extracting and
sorting, would be a practical decision.
Also, since no capable replacement database system on the DEC 11/70 has been provided, it seems that the implementation should be totally done on the Cyber
750. Another advantage of using the Cyber 750 is that there is approximately three times the port accessibility on the Cyber than the DEC. The database systems cur rently available on the Cyber 750, besides DMS-170, are
RIM and SIR.
These database software packages were briefly explored. RIM (Relational Information Management) (19)
is based upon the relational algebra model and is de signed around a FORTRAN language base. It is oriented toward the more scientific user as it works with vectors, matrices, and floating point numbers.
SIR (Scientific Information Retrieval) (1) is a hierarchical database system. It is oriented toward the manipulation of scientific data, and may be interfaced with statistical programs such as SPSS (Statistical
Package for the Social Sciences). This orientation makes it less preferable to use the system designed in this document.
The CSUN Computer Center recently acquired a new database system, INFOFETCH (16,17), that generates COBOL code and handles relational file structures. It has ad hoc querying capabilities with logical selection criteria 101
and report generation facilities. The product was deficient in some areas of operation and vendor-supplied documentation. However, the product is being revised by the vendor and may prove to be a suitable product in the future.
4.4 Enhancements
After the system has been in operation and an evaluation done of the system by a survey of users, there will be requested changes and enhancements. Some new modules will need to be added and new or expanded data files created.
One enhancement would be to define and create a database file of the classes to be offered in future semesters (created by the department) along with a data file of core requirements. This would allow the advisor and student to prepare a program of courses that will meet his degree requirements and provide a list of those courses the student should (or could) take in order to graduate. This list would be updated after each semester to reflect: the classes the student had completed~ course offerings that have changed; and the revised schedule of requirements.
4.5 Conclusions
On-line computer advisement can be of great benefit to both the faculty member and the student.
The faculty member must be available to the student, 102
knowledgeable about the various curricula and associated requirements and regulations, and interested in assisting the students in selecting a balanced program of study.
The design presented in this document only assists the faculty member in doing the job. If it were not for the personal interest and individually-unique suggestions and recommendations that an advisor can also contribute to the advising process, it might be possible to have the student interact directly with a computer.
With a comprehensive and thoroughly tested interactive computer system, the advisement process could be accom plished without direct interacting with a faculty member unless the student prefers personal advisement or has a special problem that the computer system could not han dle. The personal touch of a human advisor can sometimes be of considerable value to a student. In the future, economies of time and lack of faculty (human) resources may require that the student receive the majority of advisement information through interfacing with a com puter system.
The scenario described next is interesting. A student goes into an "advising room" and sits down at a terminal. He identifies himself to it and then interacts via a series of menus and dialogue transactions that allow the computer to print out a schedule of classes that the student should take next term, and it also 103
Q ' prints a projected schedule for the remaining terms, if requested.
Conceptually, this process could even be con nected to a computer-assisted registration process whereby the student could immediately be enrolled in future classes Department chairs and school deans could be given enrollment data and forecasts, thereby better enabling them to plan their offering of classes and placement of instructors for optimum efficiency.
Better advisement tools for both faculty advisors and students will lead the way to significantly improved advisement processes. WORKS CONSULTED OR BIBILOGRAPHY
1. Anderson, Gary D. et al. Scientific Information Retrieval (SIR) User's Manual. Evanston, Illinois: SIR, Inc., February 1981. 2. AMCOR Computer Corporation. Ambase Programmer's Reference Manual. Version 1.0, Release 1.6. Louisville, Kentucky, 1982.
3. Ambase Report Generator Subschema Librarian Query Language. Version 1.0, Release 1.6. Louisville, Kentucky, 1982. 4. Ambase Screen Generator. Version 1.0, Release 1.6. Louisville, Kentucky, 1982.
5. Ambase Utilities Manual. Version 1.0, Release 1.6. Louisville, Kentucky, 1982.
6. Chin, Collin et al. "Large System Development." Class project document from CSUN Comp. 480 Class (Large System Design). Northridge, Calif.: California State University, Northridge, November 1982.
7. Control Data Corporation. DMS-170 Cyber Database Control System Version 2 Reference Manual. Publicaton No. 60481800D. Sunnyvale, Calif., October 1980.
8. DMS-170 Data Administrator User's Guide. Publication No. 604991008. Sunnyvale, Calif., October 1980. 9. DMS-170 Data Base Utilities Version 1 Reference Manual. Publication No. 60498800D. Sunnyvale, Calif., March 1978. 10. DMS-170 DDL Version 3 Reference Manual Volume 1. Publication No. 60491900D. Sunnyvale, Calif., September 1980. 11. DMS-170 DDL Version 3 Reference Manual Volume 2. Publication No. 60482000. Sunnyvale, Calif., September 1980.
104 105
12. DMS-170 DDL Version 3 Reference Manual Volume 3. Publication No. 60482100C. Sunnyvale, Calif., September 1980.
13. DMS-170 Query Update Version 3 Programmer User's Guide. Publication No. 60499000B. Sunny vale, Calif., August 1978.
14. DMS-170 Query Update Version 3 Reference Manual. Publication No. 60498300F. Sunnyvale, Calif., October 1980.
15. DMS-170 Query Update Version 3 User's Guide. Publication No. 60387700A. Sunnyvale, Calif., January 1976.
16. Magna Business Systems Corporation. Infofetch Reference Manual. New York, 1982.
17. Infofetch User's Guide. New York, 1982.
18. North County Computer Services. User-11 Data Management System. User-11 Intermediate Class Handout. San Diego, April 5, 1982.
19. RIM Technology Incorporated. Relational Information Management System User's Manual. Version 5.0. Kirkland, Wash., 1982.
20. Spencer, Robert W. et al. "Advisement by Computer (ABC): A Tool for Improving Academic Advising." College and University (Winter 1982):169-177.
21. Thompson, Dave. "Menu-170." Internal Document. Computer Center, California State University, Northridge, 1983. APPENDICES
A DEPARTMENT INFORMATION
B. FILE DESCRIPTIONS
C. SAMPLE ADVISE-DEPARTMENT-INFO FILE
D. AMBASE SCREEN UPDATING INSTRUCTIONS
E. LISTING OF BASIC+2 SOURCE PROGRAMS
F. LOGIC FLOW: BATCH MODULES
G. LOGIC FLOW: INTERACTIVE MODULES
H. STUDENT TO FACULTY LOAD BALANCING CONSIDERATIONS
106 107
APPENDIX A
DEPARTMENTAL INFORMATION
1. CSUN Computer Science Departmental Evaluation Form
2. Computer Science Core Course Equivalency with Other Colleges
3. Computer Science Year-to-Year Course Equivalency
4. Department of Computer Science Concentrated Studies
5. Prerequisite Structure Computer Science B.S. Core
6. Sample Computer Science Class Schedule 108
CSUN DEPARTMENTAL EVALUATION COf1PUTER SCIENCE Name------Telephone------File No. Home Address Transferred From ------Advisor------
CORE Reqd Grade Sem Units Satisfied by Transfer REQUIREMENTS Units Course Units School Colll!lents Camp 122 3 Camp 132 3 Camp 182 3 Phil 230 4 Math 150A 5 Math 1508 5 1 05 FOR or Pro f. 0 1 OS COB or Prof. 0 Camp 222 3 ' Camp 232 3 Comp 242 2 Math 262 3 Engr 200 3 Engr 355 3 Math 441 3 Math 482 3 Camp 310 3 - Camp 322 3 Camp 332 3 Comp 380 3 Camp 450 3 Camp 470 (3)} Math 481A(3) 2 or 3 Engr 309 (2)
CONCENTRATED Prior approval by STUDIES COURSE advisor and Oept. 12 units up.di Chair required: I I
AREA OF STUDY:
TRANSFER EVALUATION by------Date------When signed below and transmitted to the graduation clerk, the above program co1stitutes the major requirements for graduation for this student. By ______------Student Date Advisor Date Chairman Date 2/Rl March 83 CO~IPUTER SCIENCE CORE EQUIVALENCIES
CSUN Antelope College East Glendale LACC ~lfssion Moorpark Pasadena Pierce Santa Valley. Ventura West Valley of the LA Monica LA 1' Canyons . COHP DP 40 cs 101 BOP 1 · CIS 110 BOP 1 BOP 1 OP 60 CSl or OP 2 • CS 1 or IS 1 CS 1 or 100 &42A or 22 or 21 or 22 31 3 3 or 22 . .
101 BOP 2 CS 2 or cs 37 'cs 39 f OP 64 J .. 't05BAS OP 42B BOP 55 CIS 120 BOP 21 BOP 55 DP 33 cs 23 cs 32 IS 6 ; ' .. ' . 105COB OP 44 cs 120 BOP. 29 BOP 29 BOP 29 OP 53 cs 9 OP 11 CS11 IS 7A cs ll .j or.70 l Math 11 cs 27 105FOR or cs 125 BOP 27 Hath 130 BOP 27 cs 18 OP 43 cs 25 OP 36 CS 36 or OP 48 or or or or 43 or Engr 15 Hath 44 CIS 150 Hath 44 Hath 44 . 105PAS CIS 130 .... cs 16 cs 19
122 cs 122 cs 30 cs 22 DP 18 cs 18 cs 18 & .., &40 &40 &40 37
132 cs 132 cs 10 cs 19 . &37 ... .. 182 • 182L cs 182. . cs 20 cs8 182L (182 . only) -- - ·-- -··-- -- -· ---- ·--·-- --- I-' 0 1.0 .. March B3 I CO~IPUTER -SCIENCE CORE EQUIVALENCIES
CSUN Antelope College East Glendale LACC flfssfon Moorpark Pasadena Pferce Santa Valley. Ventura West i Valley of the LA Monica LA Canyons 222 cs 222 cs 40 I 50
232 cs 232 cs 4
242 cs 242 cs 50 cs 4B cs 48
' 281, 281L OP 45 cs 33 BOP 30 BOP 30 BOP 30 cs 10 Ott 12 cs 12' cs 12 • ENGR ENGR 10 cs 6 200 i
11ATH Math Math Math 41 , Math Math 41, ~lath 41, Math Math Math 41 Hath Math 41 Math Math 41 ,; lSOA,B 1A,Il 211,212 42 or 103,104 42 or 42 or 25A,B SA,B 42 or 7,8 42 or 21A,B 42 or ~ Math 7,S Math 7,8 Math 1 ,a Math 7,8 Math 7,8 Math 7,8i I f 250 Math Math Math 11 ~lath Math 11 Math 11 ~lath Math Math 11 Math 11 Math 11 Math Math 11 7C 213 or 43 105 or 43 or 43 25C 5C or 43 or 43 21C . or 43 I
262 Plath 214 Math 13 Math 13 Math 13 Math 31 Math 10 Math 13 Math 13 Math 13 Math 131
280 Math 12 Math 21! Math 12 Math ~lath 12 Math 35 Math 55 Math 12 Math 15 Hath 12 Math 24 Math 12 or 15 106 or 15 or 15 or 15
PHIL Phfl 9 Phf1 9 Phfl 9 Phf1 33 Phfl 9 Phf1 9 Phfl 9 Phfl 9 230 • ACCT Bus Acct Acct Acct Acct Acct Bus Acct Acct Acct Acct Bus Acct 220A,B lA,B 201,202 1 ,2 101,102 1,2 1 ·? 1A,B 1A,B 1 ,2 1 ,2 1 ,2 1A,B 1 ,2 ------
I-' I-' 0 !!Q::ll 79-80 77-78 and 78-79 100 Computers, Impact 100 Orientation Unless otherwise noted, 101 Algorithms -- Bus. with 105COB 120 Digital Computers, Intro same as 79-80. Engr. with 105FOR / 105xxx Language Labs 130SCE Replaced by 101/105FOR 122 Digital Computers (C,S, majors) 130GEtl Replaced by 101/105xxx 132 Algorithms (C,S, majors) 130CSM Replaced by 132 131 COBOL Intra, (Bus, majors); disappears. 131 COBOL Intro; replaced by 101/10500B
11 11 ---7· 0 133 BASIC Intra; 101/105BAS . ""'~ · 182 Data Structures, Progr, Design lj' 294DS Data Structures, Intro !lot in 77-78 165 Graphics j 165 Graphics f222 (Systems) Computer Organization 220 Sys. PrograDDDing 232 Programming Languages 230 Progr. Languages 242 Files, Data Bases 280 Advanced FORTRAN 280 Advanced FORTRAN 281 Advanced COBOL 281 Advanced COBOL Not in 77-78 310 Theory of Abstract languages 310 Theory of Abstract Languages 410 in 77-78 and 78-79 322 Operating Systems, Sys. Arch, 320 Operating Systems Not in 77-78 and 78-79 325 Microprogramming Techniques 325 Micro. 425 in 77-78 331 Simulation Languages 331 Simul. Lang. 332 Programming Lang, Semantics <.350: see below) 361 Text Processing 361 Text Processing 461 in 77-78 365 Graphics Systems, Design 365 Graphics Sys, Design 465 in 77-78 380 Program Design 380 Program Design 385 Intermediate Computing Techniques 385 Interm. ComR• Tech. 410 Operating Systems 4l9 Operating Systems 430 Compiler Construction 430 Compiler Construction 440 File Processing; disappears. 460 File Processing 440 Spr,82: Data Base Design 450 Societal Issues 350 Computers and Society -Also in 79-80: -----i 124 Comp. Sys. & Programming 470 Numerical Methods 470 Numerical Methods (J'I'i :? (vith 130GEII or .130SCE is ·· ·- equivalent to 120 and . Lerg~!lystem Design 480 La;&O System Design ~ 480 130CSH.) . i l/O!'ASJ\1 ~ay kJ:~ ~~ 2_ ~~~r I-' f-1 f-1 112
DEPARTMENT OF COMPUTER SCIENCE CONCENTRATED STUDIES
During the sophomore year each student will meet with his or her advisor and pl~n a sequence of courses appropriate to his or her career objectives. The student's program must include not less- than 15 units. The 15 unit program may be chosen from the currently available concentrated studies packages or may be planned in consultation with the student's advisor. In the latter case the sequence must contain at least 12 upper division units and must be approved by the student's advisor and the Department Chair. Approval for any course substitution must obtained from the student's advisor and the Department Chair prior to enrolling in the course.
With the approval of the Computer Science Department, certain Computer Science experimental courses will be·allowed as substitutions in the con centrated studies packages.
Any student graduating from CSUN may elect to graduate under the catalog requirements in effect at the time of his or her graduation. This means that students graduating in Fall 83 or later may elect the 15 unit Concentrated Studies program. Students may satisfy general education requirements and com puter science major requirements from different catalogs.
6/83 113
CONCENTRATION IN COMPUTER SYSTEMS
COMP 494ARCH Computer Systems Architecture (3) COMP 325 Microprogramming Techniques & Applications (2) COMP 325L Microprogramming Techniques &.Applications Lab .(1) ENGR 459 Microprocessor Systeins ( 4) Select 6 units from; COMP 420 Principles of Operating Systems (3) COMP 428 Distributed Teleprocessing Systems (3) COMP 465 Computer Graphics Systems & Design {2) COMP 465L Computer Graphics Systems & Design Lab .(1) ENGR 456 Design of Digital Computers (3) COMP 424 Computer Systems Security (3)
Total Number ~f Units------~------16
CONCENTRATION IN . INFORMATION SYSTEM DESIGN
COMP 440 Database Design (3) COMP 480 Large Systems Design .(2) COMP 480L Large Systems Design Lab (1) COMP 424 Computer System Security {3) Select 6-7 units from: COMP 428 Distributed Teleprocessing Systems (3) COMP 465 Computer Graphics Systems & Design {2} COMP 465L Computer Sraphics Systems & Design Lab {1) COMP 461 Text Processing &Applications to Office Automation (3) ENGR 459 · Microprocessor Systems ( 4) .
COMP 494ARCH Computer Systems Architecture (3) 1' COMP 420 Principles of Operating Systems (3) . · Total Number of Units------15-16 114
CONCENTRATION IN APPLIED INFORMATION SYSTEMS
COMP 440 Database Design (3) COMP 480 Large Systems Design (Z) COMP 480L Large System Design lab (1) ACCT ZZOA Principles of Accounting I (3) ACCT ZZOB Principles of Accounting II (3) Choose one of: ACCT 324 Computer Based Management Information Systems (3) ·. . ' ACCT 455 Computer Systems Design for Business I Applications (3) . ACCT 495 Accounting Information Systems (3)
Total Number of Units------15
Students may take ACCT 324 without the ACCT 223 prerequisite but they are advised by the Accounting and 11anagement Information Systems Department to take .~CCT 320A and ACCT 323 before taking ACCT 455 or 495. 115
CONCENTRATION IN SCIENTIFIC PROGRAMMING
MATH 250 Mathenatical Analysis III (3) MATH 280 Applied Differential Equations {3) MATH 481A,S Numerical Analysis* (6) Select 3-4 units from: ·caMP 431 Simulation Languages (3) COMP 465 Computer Graphics System and Design (2) COMP 465L Computer Graphics System and Design (1) ENGR 406/408 Analog/Hybrid Computation &Lab (4)
Total Number of Units------15-16 *Students must take COMP 470 to meet core requirement on numerical analysis/methods
·- -,.. ------·
CONCENTRATION IN SOFTWARE ENGINEERING AND PROGRAMMING SYSTEMS
COMP 420 Principles of Operating Systems (3) · COMP 430 Compiler Construction (3} COMP 480 Large System Design (2) COMP 480L Large System Design Lab (1) Select 6 units from: COMP 440 Database Design (3) COMP 461 Text Processing &Applications to Office Automation (3) COMP 465 Computer Graphics Systen and Design (-2-) COMP 465L Computer Graphics System and Design Lab (1) COMP:'469 Introduction to Artifical Intelligence (3) SOMP 428 Distributed Teleprocessing Systems (3) COHP 424 Computer Systems Security (3) COMP 431 Simulation Languages (3) Total Number of Units------15 116 p '
CONCENTRATION IN LANGUAGE FOUNDATIONS.
COMP 469 . Introduction to Artificial Intelligence (3} COMP 430 Compi 1er Construction (3} · ENGL 403 Transformational Grammar (3) Choose two of: PHIL 331 Symbolic logic II (4} PHIL 432 Semantic Theory (3) PHIL 445 Philosophy of.language (3} ANTH 435 Morphology and Syntax (3) ENGL 401 language and linguistics (3) or ANTH 310 Anthropological linguistics (3)
Total Number of Units-_~--:--~------7------16
.. . ~-. ------·· ------~- --
CONCENTRATION IN MATHEMATICAL AND LOGICAL FOUNDATIONS
MATH 364 Elementary Modern Alge. bra (3) PHIL 331 Symbolic Logic II (4) I Choose three of: MATH 326 Fundamental Concepts of Mathematics (3) MATH 426A Mathematical LO!iic & Set Theory I (3} PHIL 431 Advanced Logic l3) PHIL 432 Semantic Theory (3) PHIL 430 Philosophy of Mathematics (3) MATH 464 Advanced Modern Algebra (3) MATH 466 Algebraic Structures (3) ·
Total Number of Units------16 117
CONCENTRATION IN STATISTICS
MATH 250 Mathematical Analysis III (3) MATH 340 Introducto~ Probability (3)* MATH 440A Mathematical Statistics I (3) MATH 4408 Mathematical Statistics II (3) COMP 431 Simulation Languages (3) _ Choose one of: MSCI 306 Production and Operations Management (3) MSCI 316 Quantitative Analysis in Business (3) MSCI 409 Operations Research (3) MSCI 469 Advanced Statistical Methods in Business and Economics (3) _ MATH 442 Topics in Statistics (3) MATH 465 Introduction to Linear Programming (3)
Total Number of Units------15
*To be substituted for core s~atistics requirement.
CONCENTRATION IN THEORETICAL COMPUTER SCIENCE
COMP 420 Principles of Operating Systems (3) COMP 430 Compiler Construction (3) COMP 440 Database Design (3) Choose two of: ENGl 403 Transformational Grammar (3) MATH 325 Fundamental Concepts of Mathematics (3) MATH 364 Elementa~ Modem Algebra (3) MA'tH 426A Mathematical Logic and Set Theo~ I (3) MATH 466 Weak Algebraic Structures (3) PHIL 331 Symbolic Logic II (4) PHIL 430 Philosophy of Mathematics (3) PHIL 431 Advanced Logic (3) - PHIL 432 Semantic Theo~ (3)
Total Number of Units------15-16 118
January 1982
PREREQUISITE STRUCTURE(]) COMPUTER SCIENCE B.S. CORE FALL 1982
Math Num.Methods 150A Choose one 150B 262 Comp 470 441 Engr 309 482 Math 481A (1) A "C~ or better is required in a 11 prerequisites to Computer Science Core Courses (2) Satisfactory Math Placement Test Score (3) Comp 132 must be taken before or concurrently with Comp 122 ( 4) FORTRAN (COBOL) Proficiency Exam or grade "C" or better in 105FOR ( 105 COB) (5) Qualifying grade on Computer Science Qualifying Test required for Comp 310, 322, 332, 380. CSQT may be taken concurrently with Comp 222,232. (6) Senior Standing (7) Math 150B corequisite 119
IIOR PROP SPRING 1984 11/28/83 100 51000 RNP OJ00-0950 41J 112 100 51001 RN 1400-1515 419 GUbut sun TTR ll00-1250 107 li2L SlllO T lJ00-1545 134 100 51003 TTR OIOO-OJ15 41J li2L 51131 100 51004 TTR 1100-1715 lila TR 1300-1545 134 liZ 515H TTl 1100-1150 107 100 51500 ~ 1030-1145 1l1a 112L 51524 T U00-2145 134 112L 51525 D 101 51007 RW 0100-0150 311aPattarao U00-2145 134 101 51001 MW 1000-1050 41J Bader 1J4cga51011 T8 1501-1745 107 Feder 101 51009 RN 1300-1]50 31J Raddua 101 51010 RN 1400-1450 l1J Lorbeer 222 51011 IINP 0100-0150 13J B•lth 101 51011 RN 1500-1550 llJ Lorbeer 222 510&7 RNP 1000-1050 213 S•lth 101 51014 TTR OJOO-OJ50 31J Dou9laa 222 51011 TTl 1530-1145 213 Sa1a.oa 101 5101% TTR 1000-1150 3IJ Ror9an 222 51530 TTR 1J00-2015 151i Saloaoa 111 51013 TTR 1100-1150 107 lorgaa 101 510%1 TTR 1400-1450 31J 232 5101J RNr 1100-1150. llJ Stepanek 101 51015 TTl 1100-1150 31J 232 51070 TTR 0100-0J15 13f 101 51505 " 1J00-1050 107 232 51071 1400-1515 13J larketakl 101 51502 T 1J00-1050 107 TTR 101 51503 w 1900-1050 107 232 51531 TTB 2030-2145 llJ Barkatakl 101 51504 T8 1900-2050 107 242 51073 IINP OJOD-oJ50 213 Ra1llpad1 242 51075 RW 1400-1515 417 Saith. 105co 51021 II 0101-1045 141 242 51074 TTB 1100-1%15 417 Bacnea 105co 51021 R 1101-1345 141 Gilbert _242 51551 liN 2030-2145 213 Ra111pud1 105co 51022 T 1100-1345 141 larkatakt 1D5co 51023 T8 UOD-1345 Ul 310 51010 IINr 0100-0150 417 Grant 105co 51501 T U00-1145 141 105co 51501 Uo0-1145 141 311 51011 IINP ll00-1350 101 Grant w 311 51552 liN 2030-2145 151 Henderaoa 105co 51510 D lJ00-2145 1U 322 51113 liN IIDD-1151 41J Stepanek 105fo 51024 II II00-1045 121 Barel 322L 51132 N 1400-1145 121 Stepanek 1D5fo 510%5 II 1100-1345 121 Schwarta 322L 51014 r 0100-1045 121 Stepanek 105fo 51021 T 0100-1045 121 . 322 51015 TTB 1300-1350 41J Schwartz 105fo 51027 T uoo-1345 121 l22L 51011 T 1.400-UU 121 Schwartz 105fo 510U W 1100-1345 121 lalo.oa 322L 51133 TB 1400-1145 121 Bchwact• 105fo 31021 TB 0100-1045 121 105fo stUD D l2:Z 51532 liN 1100-1150 151 uoo-u45 121 322L 51533 II 1J00-2145 121 105fo 51134 P 1101-1345 121 Borg.. l22L 51553 W 1J00-2145 121 10Sfo 51031 P 1400-1145 121 105fo 51515 P. noo-uu 121 325 51017 RW 1300-1350 Co1 ..a l05fo 51514 T Uo0-2145 121 l25L 51011 1101-1345 411 Co1 ..a 1051o 51512 D U00-2145 121 r 122· 51135 RNP OIOD-0151 l1J Ra11lpadl 332 5101J IIW 1401-1515 213 Gu.O 122 51035 RWP OJOO-OJSO l1J 332 51554 liN 1730-1145 41J au.b 122 51037 TTB OIOO-OJ15 107 Bargaa 311 51Df5 IINP OJOO-OJSD l11eA1anen 12% 51031 TTl 1400-1515 llla 310 510'1 liN 1400-1515 141bA1anen 122 51511 IIW 1JOI-2015 131aRa11lpudl 310 51555 liN 1731-1145 101 Gl1bert 132 51041 RNP OIOI-1150 107 Alanaa 421 51535 TTB lf00-2015 IliA Barkatakl ll:Z 51042 RNP 1000-1050 31J Grant 422 51091 TTR 1530-1145 211 Turn ll:Z 51045 RNP 1300-1350 213 A1anea 424 51557 TTR 1730-1145 llJ Turn 132 51043 IIW 1500-1120 3llaarant 440 51531 w 1J00-2145 13J Landla 132 51044 TTl OJl0-1045 107 Rot11 450 51537 TTl 2030-2145 41f Turn 132 5151J TTl 1J00-2015 41J 411 510Jf RW 1530-1150 101 S•lth 471 51100 TTB 0930-1045 41J Schwacta 115 51151 p JOOI-1251 411 radar 410 51101 liN 1000-1050 107 Abbott 410L 51102 RW 1100-1215 107 Abbott li:Z 5105411W 0101-0151 1541 4J4SB 51510 R lf00-2145 llt G1aa•an 112L 51051 " U00-1145 134 112L 4f4HCI51103 TTl 1400-1530 417 Bernea 51057 w DJOD-1145 134 4J4LP 5155t liN 1100-2015 151 Gu.O 112 51051 11W 1500-1551 411i Rendaraon li2L !lOst II 1200-1445 134 Renderaon 505 51545 " 11ao-1isa 101 Abbott JilL 5101i0 w 1200-1445 134 Benderaon 520 51541 TTR 2030-2145 151 Salo.on 112 51051 ... 1500-1550 154jCo1aan · 530 51547 TTR 1f00-2015 1lJ Guab li2L 51062 II 1100-1145 134 Co1 ..n liN 51063 11 510 51541 1900-2015 41J Gilbert 1UL lli00-1145 134 Co1 ..n 5J1 5154f w 1100-1150 107 Abbott Q .
APPENDIX B
FILE STRUCTURES
1. DISK-STUDENT-MASTER File Description
A. DISK-STUDENT-RECORD Description
B. Initial-Record Description
2. COURSE-MASTER-DISK File Description
120 121
000680 FD DISK-STUDENT-MASTER 000680 RECORD CONTAINS 600 CHARACTERS 000685 BLOCK CONTAINS 39 RECORDS .- 000690 LABEL RECORDS ARE OMITTED. 000780* 000750 01 DISK-STUDENT-RECORD. 000760 02 FILE-NUMBER PICTURE XC 7 >• 000770 02 FILE-NUMBER-N REDEFINES FILE-NUMBER 000780 PICTURE 9(7). 000790 02 ALPHA-NUMBER PICTI,JRE X<6>. 000800 02 ALPHA-NUMBER-N REDEFINES ALPHA-NUMBER 000810 PICTURE 9C6>. 000820 02 NAME PICTURE XC20 >. 000830 02 ADDRESS-X PICTURE XC20 >. 000840 02 CITY PICTURE X< 18). 000850 02 ZIP-CODE PICTURE xxxxx. 000860 02 FILLER PICTURE xxxx. 000870 02 STATE PICTURE XX. 000880 02 SOCIAL-SECURITY .. PICTURE X<9>. 000890 02 PERMANENT-RESIDENCE PICTURE XXXX. 000900 02 PERMANENT-RESIDENCE-N REDEFINES PERMANENT-RESIDENCE 000910 PICTURE 9(4). 000920 02 MAJOR PICTURE XCS>. 000930 02 MAJOR-N REDEFINES MAJOR PIC 9<5>. 000940 02 CREDENTIAL-OBJECTIVE PICTURE 'XXXXX. 000950 02 BASIS-FOR-ADMISSIONS PICTURE X. 000960 02 CLASS-YEAR PICTURE X. 000970 02 CLASS-YEAR-N REDEFINES CLASS-YEAR PIC 9. 000980 02 DATE-OF-BIRTH PICTURE X< 6 >• 000990 02 ENROLLMENT-STATUS PICTURE X. 001000 02 ENROLLMENT-STATUS-N REDEFINES ENROLLMENT-STATUS 001010 PICTURE 9. 001020 02 ENROLLMENT-TYPE PICTURE X. oo1o:=:o 02 ELIGIBILITY-STATUS PICTURE XX. 001040 02 SEX-CODE PICTURE X. 001050 02 SEX-CODE-N REDEFINES SEX-CODE PIC 9. 001060 02 MARITAL-STATUS PICTURE X. 001070 02 RESIDENCE-STATUS PICTURE X. 001080 02 SPECIAL-GROUP-CODE PICTURE X. 001090 02 HOUSING-CODE PICTURE X. 001100 02 VETERAN-CODE PICTURE X. 001110 02 PROBATION-CODE PICTURE X. 001120 02 DISABLED-CODE PICTURE X. 001130 02 DEGREE-OBJECTIVE PICTURE X. 001140 02 REGISTRATION-STATUS PICTURE X. 001150 02 LATE-OR-WITHDRAWAL-DISK PICTURE X. 001160 02 SS-ENRL-STATUS PICTURE X. 001170 02 SS-ENRL-TYPE PICTURE X. 001180 02 58-ATTENDANCE PICTURE XX. 001190 02 SUMMER-SESSION-1.-DISC PICTURE X. 001200 02 SUMMER-SESSION-2-DISC PICTURE X. 001210 02 REGISTRATION-NUMBER PICTURE XXX. 001220 02 REGISTRATION-NUMBER-N REDEFINES REGISTRATION-NUMBER 001230 PICTURE 999. 001240 02 CENSUS-UNITS PICTURE 999V9. 122
001250 02 CENSUS-UNITS-A REDEFINES CENSUS-UNITS 001260 PICTURE X<4l. 001270 02 UNITS-ATTEMPTED-CURRENT-SEM PIC 999V9. 001280 02 UNITS-PASSED-CURRENT-SEM PIC 99V9. 001290 02 GRADE-POINTS-EARNED-CURRENT-SM 001295 PICTURE 999V9. 001300 02 CSUN-UNITS-ATTEMPTED PICTURE 999V9. 001310 02 CSUN-GRADE-POINTS PICTURE 999V9. 001320 02 CSUN-UNITS-EARNED PICTURE 999V9. 001330 02 GP-DEFICIENT PICTURE 99V9. 001340 02 NEW-RET-FROM-SS-DISC PICTURE X. 001350 02 FILLER PICTURE X. 001360 02 EVAL-BEG-DAY-WEEK PICTURE XXX. 001370 02 EVAL-BEG-DAY-WEEK-N REDEFINES EVAL-BEG-DAY-WEEK 001380 PICTURE 999. 001390 02 EVAL-END-DAY-WEEK PICTURE XXX. 001400 02 EVAL-END-DAY-WEEK-N REDEFINES EVAL-END-DAY-WEEK 001410 PICTURE 999. 001420 02 APPL-REC-DAY-WEEK PICTURE XXX. 001430 02 APPL-REC-DAY-WEEK-N · .· REDEFINES APPL-REC-DAY-WEEK 001440 PICTURE 999. 001450 02 ACT-COMPOSITE-SCORE PICTURE XX. 001460 02 SAT-MATH-SCORE PICTURE XX. 001470 02 SAT-MATH-SCORE-N REDEFINES SAT-MATH-SCORE 001480 PICTURE 99. 001490 02 ENTRY-LEV-MATH-CODE PICTURE X. 001500 02 SAT-VERBAL-SCORE PICTURE XX. 001510 02 SAT-VERBAL-SCORE-N REDEFINES SAT-VERBAL-SCORE 001520 PICTURE 99. 001530 02 UPPER-DIV-WRITING-SKILLS PIC X. 001540 02 HS-YEAR-OF-GRAD PICTURE XX. 001550 02 HIGH-SCHOOL-GPA PICTURE 9V99. 001555 02 IMPACTION-SCORE PICTURE 9999. 001556 02 IMPACTION-SCORE-A REDEFINES IMPACTION-SCORE 001557 PICTURE X<4l. 001560 02 CORE-GPA PICTURE 9V99. 001561 02 CORE-GPA-A REDEFINES CORE-GPA 001562 PICTURE X<3l. 001565 02 FILLER PICTURE X. 001570 02 INSTITUTION-LAST-ATT PICTURE X( 6 l • 001580 02 INSTITUTION-LAST-ATT-N REDEFINES INSTITUTION-LAST-ATT 001590 PICTURE 9(6). 001600 02 LAST-ATTENDED-YEAR PICTURE XX. 001610 02 PERMIT-CODE PICTURE X. 001620 02 END-OF-TERM-UPDATE-FLAG PICTURE X. 001630 02 FILLER PICTURE X(3). 001640 02 PACKET-FLAG PICTURE X< 14). 001650 02 RECORD-STATUS PICTURE X. 001660 02 REDIRECTED-CODE PICTURE X. 001670 02 HOLD-CODE PICTURE X. 001680 02 LAST-CHANGE-DATE PICTURE X<8>. 001690 02 LAST-CHANGE-TIME PICTURE X<4l. 001700 02 MASTER-ON-D I SC-FL.AG PICTURE X. 001710 02 DELETE-CODE PICTURE x. 001720 02 REGISTRATION-ADD PICTURE X. 001730 02 DROPPED-DURING-3-WEEK PICTURE X. 123
001740 02 TICKET -AREA. 001750 03 TICKET-GRADE PICTURE X(8) OCCURS 15 TIMES. 001760 02 TICKET-AREA-N REDEFINES TICKET-AREA. 001770 03 TICKET-GRADE-N OCCURS 15 TIMES. 001780 05 TICKET-N PICTURE 9<5>. 001790 05 FILLER PICTURE XXX. 001800 02 RECORD-TYPE PICTURE X. 001810 02 CREDENTIAL-STATUS PICTURE X. 001820 02 CITIZENSHIP PICTURE X. 001830 02 ETHNIC-CODE PICTURE x. 001840 02 FIRST-TERM-ATTENDED PICTURE X. 001850 02 FIRST-YEAR-ATTENDED PICTURE XX. 001860 02 CSUN-GPA PICTURE 9V99. 001870 02 TRANSFER-UNITS-ATTEMPTED PIC 999V9. 001880 02 TRANSFER-UNITS-EARNED PICTURE 999V9. 001890 02 TRANSFER-GRADE-POINTS PICTURE 999V9. 001900 02 TRANSFER-GPA PICTURE 9V99. 001910 02 TOTAL-UNITS-ATTEMPTED PICTURE 999V9. 001920 02 TOTAL-UNITS-EARNED PICTURE 999V9. 001930 02 TOTAL-GRADE-POINTS ·.:PICTURE 9(4)V9. I 001940 02 TOTAL-GPA PICTURE 9V99. I 001950 02 STATE-INTENT-TO-REGISTER PIC X. 001960 02 DEGREE-HELD PICTURE x. 001970 02 STUDENT-STANDING PICTURE X. 001980 02 GPA-CURRENT-SEM PICTURE 9V99. I 001990 02 PROGRESS-POINT-UNITS-ATT PIC 999V9. 002000 02 PROGRESS-POINT-GRADE-PTS PIC 999V9. I , 002010 02 PROGRESS-POINT-GPA PICTURE 9V99. 002020 02 PROBATION-AUDIT-TRAIL PICTURE XX. I 002030 02 GRAD-DEPT-PROBATION-CODE PIC X. I 002040 02 ADMIN-PROBATION-CODE PICTURE X. 002050 02 SPECIAL-DEPT-PROBATION-DISK PIC X. I 002060 02 SPECIAL-OTHER-PROBATION-DISK I 002065 PICTURE X. 002070 02 FILLER PICTURE X. 002080 02 CONTRACT-TYPE PICTURE X. 0020';10 02 CONTRACT-GRADE-PTS-TERM1 PIC 99. 002100 02 CONTRACT-GRADE-PTS-TERM2 PIC 99. 002110 02 CONDITIONAL-ADMISSION PICTURE X. 002120 02 ENGLISH-PLACEMENT-TEST PICTURE X. 002130 02 UNITS-DROPPED-CUR-SEM-DISK PIC 99V9. 002140 02 PHONE-NUMBER PICTURE X<10l. 002150 02 ENGL-PLCMT-TST-END-DATE PICTURE XXX. 0021
002290 02 UNITS-PAID-DISK. 002300 03 UNITS-PO-DISK PICTURE S99 OCCURS 5 TIMES. 002310 02 RECEIPT-OVERFLOW-DISK PICTURE X. 002320 02 BOS-FLAG-DISK PICTURE X. .. 002330 02 STUDENT-LV-ELIGIBLE-FLAG PIC X. 002340 02 STUDENT-LV-SEMESTER-FLAG PIC x. 003990 02 SPEC-PROG-CODE-1 PICTURE XX. 003992 02 SPEC-PROG-CODE-2 PICTURE XX. 003994 02 SPEC-PROG-CODE-3 PICTURE XX. 003996 02 SPEC-PROG-CODE-4 PICTURE XX. 003997 02 ADM-STAT-DTE-APLD-YMD PICTURE X(6). 003998 02 DIRECTORY PICTURE X. 004000 02 FILLER PICTURE X<63>. 125
039000 01 INITIAL-RECORD. 039100 03 INIT-REC-NUMBER PIC X(7). 039200 03 INIT-REC-TITLE PIC X< 6 >. .- 039300 03 FILLER PIC X<1U. 039400 03 !NIT-SEMESTER PIC X< 4 >. 039500 03 INIT-VEAR-AND-TERM. 039600 05 INIT-VEAR PIC 99 VALUE 00. 039700 05 FILLER PIC x. 039800 05 IN IT-TERM PIC X. 039900 03 INIT-RUN-TVPE PIC X<4>. 040000 03 FILLER PIC X(68). 040100 03 !NIT-PROGRAM PIC X. 040200 03 I NIT-RERUN-CODE PIC 9999 VALUE ZERO. 040300 03 !NIT-RERUN-DATE PIC X. 040400 03 FILLER PIC X<88>. 040500 03 !NIT-DELETE-COUNT PIC 9(8) VALUE ZERO. 040600 03 FILLER PIC X VALUE ZERO. 040700 03 I NIT-TIME PIC X(8). 040800 03 INIT-STUDENT-REC-COUNT PIC 9(8) VALUE ZERO. 040900 03 FILLER PIC X(356). 126 0 '
006030 FD COURSE-MASTER-DISK 006040 RECORD CONTAINS 640 CHARACTERS 006050 LABEL RECORDS ARE OMITTED. ,. 006080* 006100 01 DISK-COURSE-MASTER-RECORD. 006120 03 CLASS-RECORD OCCURS 2 TIMES. 006130 05 CL-TICKET PICTURE 9(5). 006140 05 CL-DEPARTMENT PICTURE X< 4>. 006150 05 CL-COURSE-NUMBER PICTUR'E X(6). 006160 05 FILLER PICTURE X<4 >. 006170 05 CL-TITLE PICTURE X(17>. 006180 05 FILLER PICTURE x. 006190 05 CL-INSTRUCTOR PICTURE X( 14>. 006200 05 FILLER PICTURE XX. 006210 05 CL-UNITS PICTURE 9V9. 006220 05 CL-DAYS-CLASS-GIVEN PICTURE X<5>. 006230 05 CL-STARTING-TIME PICTURE X<4>. 006240 05 FILLER PICTURE XXX. 006250 05 CL-PLACE-CLASS-GIVEN PIC X<6>. 006260 05 CL-ENROLLMENT-LIMIT PICTURE 999. 006270 05 CL-YEAR-AND-TERM PICTURE XXX. 006280 05 CL-CLASS-ENROLLMENT PICTURE 999'. 006290 05 CL-EXTENDED-UNITS PICTURE 9<5>V9. 006300 05 CL-HEGIS-CODE PICTURE X< 5 > • 006310 05 CL-INSTRUCTIONAL-LEVEL PIC )(. 006320 05 FILLER PICTURE X (6). 006330 05 CL-CLASSIFICATION PICTURE XX. 006340 05 CL-TO-BE-ARRANGED-HRS PIC XX. 006350 05 CL-SCHOOL-CODE PICTURE XX. 006360 05 FILLER PICTURE X< 4 > • 006370 05 CL-LOW PICTURE 9<4>. 006380 05 CL-HIGH PICTURE 9<4>. 006390 05 CL-GRAD PICTURE 9<4>. 006400 05 CL-CANCEL-FLAG PICTURE X. 006410 05 CL-ENDING-TIME PICTURE X< 4 ) • 006420 05 CL-FACILITY-TYPE PICTURE X. 006430 03 CLASS-RECORD-PART-2 OCCURS 2 TIMES. 006440 05 CL-AUD IT-COUNT PICTURE 999. 006450 05 CL-TEAM-TEACHING-FRAC PIC XXX. 006460 05 CL-SOCIAL-SECURITY PICTURE X( 9 > • 006470 05 CL-STARTING-SEAT PICTURE 999. 006480 05 CL-TICKET-PREFIX PICTURE X. 006490 05 CL-FEE PICTURE XXX. 006500 05 CL-FOOTNOTE PICTURE X<8>. 006510 05 CL-DEPARTMENT-CCiDE PICTURE XXX. 006700 05 FILLER PICTURE X< 159). APPENDIX c
SAMPLE ADVISE-DEPARTMENT-INFO FILES (some partially listed)
PIP CSEGIUV.TXT
CSUN COURSE EQUIVALENCY WITH OTHER COLLEGES COLLEGE PASADENA OF CANYON SANTA CSUN LACC EAST/LA MISSION PIERCE VALLEY WEST/LA MOORPARK VENTURA MONICA 100 1/21/22 1/22 1/22 1/31 1/3 1/3 1 101 1B 2 101 2 37 39 2 15 5A 105APL 55 55 24 33 ASM 58 58 58 14/21 17/18 17/18 :5 9 17/18 BAS 21 55 55 23 32 14 6 COB 29 29 29 9 11 11 4A 120 7A 11 FOR 27 27 25 36/43 27 18 125 36 PAS 19 PLI 28 28/54 13 15 12 11 15 122 22&.40 18&.40 18&37 18&.40 131 29 29 29 9 11 11 4A 120 7A 11 132 19&.37 182
242 -48 48 4Air8B 33 280 26 281 30 30 30 10 12 12 48 7B 12
Readv
127 128
PPIP CSCOUR:TXT CSUN COURSE EQUIVALENCY 3-82 *** 80-81 *** *** 79-80 *** * 77-78 & 78-79 * 100 COMPUTERS.IMPACT 100 ORIENTATION UNLESS OTHERWISE 101 ALGORITHMS-BUS W/105COB 120 DIGITAL COMPUTERS.INTRO NOTED, SAME AS ENGR W/105FOR 79-80 105xxx LANGUAGE LABS 130SCE REPLACED BY 101/105FOR 122 DIGITAL COMPUTERS-CS MA~ 130GEN REPLACED BY 101/105xxx 132 ALGORITHMS-CS MA~ 130CSM REPLACED BY 132 131 COBOL INTRO-BUS MA~ 131 COBOL INTRO Rea.dv 129 "PPIP"CSCORE.TXT UNDERGRADUATE CORE PREREQUISITE STRUCTURE FALL 82 COI'IP 132 ALGORITHMS 1) NEED SATISFACTORY MATH PLACEMENT TEST SCORE COMP 122 COMPUTERS 1) COMP 132 SCREEN 2 COMP 232 LANGUAGES SCREEN 3 COMP 450 SOCIETY 1l COMP 380 2> SENIOR STANDING ENGR 200 SYSTEMS 1) MATH 150B COREQUISITE ENGR 355 MACHINES 1 l ENGR 200 COMP 310 ABSTRACT LANGUAGE 1> ENGR 200 2) PHIL 230 SCREEN 4 COMP 332 SEMANTICS 1) COMP 310 PIP CSMINR.TXT MINOR IN COMPUTER SCIENCE REQUIREMENTS 3-82 DEPT TITLE UNITS COMP 122 INTRO TO DIGITAL COMPUTERS 9 COMP 132 INTRO TO ALGORITHMS & PROGRAMMING 3 COMP 182 DATA STRUCTURES & PROGRAM DESIGN 3 (9 UNITS> COMP 222 COMPUTER ORGANIZATION 3 SELECT ANY 2 OF 3 COMP 232 CONCEPTS OF PROGRAMMING LANGUAGES 3 BY ADVISEMENT COMP 242 FILES AND DATABASES 2 (5/6 UNITS> MATH 150A MATHEMATICAL ANALYSIS I s SELECT ANY 2 OF THE 7 MATH 1509 MATHEMATICAL ANALYSIS II :5 (6/10 UNITS) MATH 255A CALCULUS I 3 MATH 2559 CALCULUS II 3 ECON 408 MATHEMATICAL ANALYSIS FOR ECONOMISTS 3 PLUS 9 UNITS OF UPPER PHIL 230 SYMBOLIC LOGIC I 3 DIVISION COMPUTER PHIL 331 SYMBOLIC LOGIC II 3 COURSES; CHAIR APPROVED ! ! Readv 131 PPIP CSGENE~TXT COMPUTER SCIENCE AND GENERAL EDUCATION REQUIREMENTS PPIP CSHAST;_TXT GRADUATE CORE PREREQUISITE STRUCTURE FALL 1981 COHP 510 DATA STRUCTURES & ALGORITHMS 1> MATH 482 ..PIP CSCONC.TXT !~8!0009 REQUIRED HEADER !! SCREEN 00 09 SCREENS !! SUBMENU HEADER 5 LINES NEXT UNDERGRADUATE CONCENTRATED STUDIES WHICH CONCENTRATED STUDIES LIST DO YOU WANT TO LOOK AT? 1. APPLIED INFORMATION SYSTEMS (15 UNITS) 2. COMPUTER SYSTEMS <1o) 3. INFORMATION SYSTEM DESIGN <15-16) 4. LANGUAGE FOUNDATIONS (1o) 3. MATHMATICAL AND LOGICAL FOUNDATIONS <1o) o. SCIENTIFIC PROGRAMMING (15-1ol 7. SOFTWARE ENGINEERING & PROGRAMMING SYSTEMS (15) 8. STATISTICS <15l 9. THEORETICAL COMPUTER SCIENCE <15-16) 10. EXIT BACK TO MAIN MENU I 88!0100 ! SUB-SCREEN CONCENTRATION IN APPLIED INFORMATION SYSTEMS COMP 440 DATABASE DESIGN (3l COMP 480 LARGE SYSTEM DESIGN (2) COMP 480L LARGE SYSTEM DESIGN LAB <1) ACCT 220A PRINCIPLES OF ACCOUNTING I (3) ACCT 220B PRINCIPLES OD ACCOUNTING II (3) PLUS CHOOSE 1 OF THE FOLLOWING: ACCT 324 COMPUTER BASED MANAGEMENT INFORMATION SYSTEMS (3) ACCT 455 COMPUTER SYSTEMS DESIGN FOR BUSINESS APPLICATIONS (3) ACCT 495 ACCOUNTING INFORMATION SYSTEMS (3) TOTAL UNITS: 15 88!0200 SUB-SCREEN 2 CONCENTRATION IN COMPUTER SYSTEMS COMP 494ARCH COMPUTER SYSTEM ARCHITECTURE (3l COMP 325 MICROPROGRAMMING TECHNIQUES & APPLICATIONS <2l COMP 325L MICROPROGRAMMING TECHNIQUES & APPLICATIONS LAB (1) ENGR 459 MICROPROCSSOR SYSTEMS (4) Q . APPENDIX D AMBASE SCREEN OPERATING INSTRUCTIONS 12.0 GENERAL OPERATING INSTRUCTIONS FOR OUTPUT PROGRM·lS Specific operating instructions will be required according to the purpose of the output program. Here are some general instructions about programs produced by AESFGN. .... 12.1 Input on Scope Oriented Output. The program, not RSTS/E, is echoing· characters. Nothing vdll be echoed until the program is ready for it. If the §perator types ahead, only data up to the first line delimiter will be recognized. The operator should not type ahead. Control/U will repr~.nt the field as it appeared before typing began and reposition the cursor to the beginni~ of the field. All other control characters (except control. c) will be ignored • . Line delimiters 'lloi.ll not be echo~d. The cursor will move to the beginning of the next i~put field when it reaches that part • >. of processing. In general, this will happen fast enough that it will look like the delimiter is being echoed by moving to the beginning of the next field. 12.2 Input on hardcopy oriented output is standard RSTS/E terminal communications. 12.3 Interrupts. The operator has a great deal of control over processing. 12.3.1 "AID" or "HELP" may be typed in response to any question. If a help message is available it will be displayed (at the bottom of the screen for scopes, underneath the prompt for hardcopy). Even if no help message is available, these 12-1 134 135 responses will never be misinterpreted as the answer to the question. On hardcopy, the user will be re-:prompted. For scopes, the field is re-printed ;.1ith its current contents and the cursor is repositioned to the front of the field •. ~ 12.3.2 "BACK" will always return the user to the most· previo11s field accessed, even though fields need not be accessed in any parti cular order. On scopes, the word "BACK" never rema-ins on the screen. It is replaced with the correct field contents. 12.3.3 "END" may be typed in response to any prompt. It may have several results, based on position and program status. If the user is at the first question for a record, control will be passed to the chain out logic. If the user is in _the middle of changing a recq.rd, the record will be stored back on disk,- and the screen will cl~ar for the beginning of another record. For hardcopy, the user will be prompted for the beginning of another record. If the user is creating a new record, the program will prompt the user to ask ·if he wishes to store the partial record he has created. 12.3.4.0 Interrupt requests may be entered in response to any prompt.: These commands all begin with "//". 12.3.4.1 //E. This interrupt directs the program to drop whatever it's doing. Current buffer contents are cleared, but not stored on disk. For scopes, the screen is re-set to begin input on a new record. For hardcopy, the user is prompted for the first 136 question for the next transaction. ·~.).4.2 //D. The current existing record (if any) is deleted from the file. The program then sets up for the next transaction. 12.3.4.3 //F##. This interrupt directs the program to jump·i~ediately to the field spec~fied in the number (for example //FlO says jump to field ten). This is not the field number per ~ffiASE definition. It is a reference number. The reference number appears to the left of each field on scope programs. It is printed with the field on //t or //P interrupts and when a value is automatically assigned and displayed on hardcopy pro&rams. 12.3.4.4 //N. The current record (if the. user is changing an existing record) is stored back on disk along with any changes made and the next record is brought into core. It is also displayed on the screen for scope programs. -For hardcopy the PRK is printed for reference. The user is prompted for the field immediately preceding the field where "//N" was typed. An operator could change all values for field 10 in a system by entering ·~//N", jumping to fie1d 10, entering a value, and typing / /N ~field 11. Control would return to the next record, field 10, allowing the user to repeat the process. 12.3.4.5 //S or //C. For scope programs only, these interrupts (which are interchangable) direct the program to either effect the changes which the user has been making on an existing record immediately or to store the new record which the user is creating. In either case, the program sets up for the next transaction. 137 12.3.4.6 //P. For hardcopy programs only, this causes the contents of the current record (except for locked fields) to be displayed to the operator. Each field is preceeded by its reference number. The user is re-prompted for the field where~the interrupt occurred. 12.3.4.7 //L. For hardcopy programs only, this causes all prompts (except for locked fields}to be displayed to the operator. Each prompt is preceeded by its reference number. -Control returns to the question where the interrupt occurred. 12.4 Defaults. If a field currently. has a value, this is al~ays offered as the default. If not, a default from the data dictionary is offered if it contains one. For-scope programs, the default is printed in the field. Carriage return is the same as re-typing the field contents. For hard~opy, the default . is printed in brackets (stan~ard· AMASK and AI·'IFASK procedure) and carriage return is the same as typing the data between the brackets. 12.5 Yes and No. The normal acceptance of line feed for "NO" and escape for "YES" is not followed by scope programs, but is available for hardcopy use. 12.6 Generic Searches. The //N interrupt may be used to perform generic searches, without knowing the exact keys which begin and end the range. The programs always start out in "Store" mode. After the sort one key is entered a find is performed. If successful, the screen is loaded with values from the record for scopes. For hardcopy the ~rogram will begin offering defaults from the existing record. 12-4 138 If the user, for example, wishes to see all AR customers whose account number begins with "09", but does no·t know the first account number in this range, he may enter "09", then hit "//N" in response to the second question. The "09" buffer,:contents will not be stored on disk, but this key will be used in a "get greater than" follow. The next record will be brought into core. Subsequent "//N" commands will bring in the other records in this range. I ' 12-5 APPENDIX E LISTING OF BASIC+2 SOURCE PROGRAM. BASIC+2 Source Program Listing of equivalent to Modules AF0125, AF0325 and AF0425 when implemented on DEC 11/70 139 140 .._ ____.:•'-"*-*---tl-** "'*-*'II 'i! '1!.'4! * ** ** • .,_._. ·-· *"'-"' *-*-* ** *·* .... **·* '* ** * "'* * * *-*-** •• * **-* * ••:. '*--*-"---&.- f COMPUTER SCIENCE ADVISE~E~T SYSTEM ICUSAS.~2Sl & & _____\.loJo!OllNL..-J::E'-'Q'-!plJR GOTO 1900._,Q"------'!'-'G!l.._I_q_~-EqROR _ji'LI_E_RPUPTS.______&_ & I VERSION: 01 & ______.:\~VuE~R~~S~l~O~N~~~~=~·~•L1L•~O~"~------J!~y~E~R~S~t~U~N~~I~O~F~O~-~S~P~P~Q~G~g~A~M~;------J&L-- I EDIT LEVEL: 01 & EDIT DATE: OI-MAR-B2 & ' AUTHOR: RH OBER~AGER & 20 !****************************************************************** ' MOQIFXCATIOJ,i-~UL------~~ VER/EO DATE REASON 01/01 01-MAR-82 PROGRAM CREATION 100 ,...... • I PROGRAM DESCRIPTION ' THIS IS A MAIN MENU SELECTION TASK WHICH WILL_AI.L\.rw !HE USER TO & I CHOUSE wHICH PA~TICULAR FUNCTION THAT HE wOULD LIKE TO PERFORM. & I THERE A~E 7 BASIC FUNCTIONS THAT THE USER CA~ REQUEST & ------'---.!.T!:!H,__,ESE ARE: &_ & 1. STUDENT HISTORICAL RECORD RETRIEVAL 2, REVIEw COMP SCI BS CORE PREREQUISITE STRUCTURE 3. REVIEW COMP SCI CONCENTRATED STUDIES & 4. REVIEw CSUN COURSE EQUIVALENCY •tTH OiHER COLLEGES & 5. REVIEW CSUN COURSE EQUIVALENCY 6. COMP SCI MINOR REQUIREMENT 7. COMP 8, COMP SCI AND ·- ·. __ . t . 9. EXIT PROGRAM ·. f 301) & CHANNEL & t. 700 '~***************************************************************** & ______IL.....>:~S::.~U 6B OUT IN E S USE p & LINE/NAME DESCRIPTION & & ' 15500 ------QISPLAY A,SCJ! TEXT FILE >ft5 liNE HEADER f. 15 DATA r. & DISPLAY ASCII TEXT FILE W/SUB MENU 1ST THEN LIKE 15600 ------& ABOVE• !5 LINES HEADER• THEN 15 DATA I INES '· 750 '****************************************************************** ------~·~E~U~N~,~~~~~------~- LINE,NAME DESCRIPTION ------~·-~J~5U0LLIU0-JF~L!l~C~S~I~C~OOL'~-I~N~E~S~Ll ______~ CuRSOR POSITIONING FUNCTION, & & J5030 FNAQfAC( NliMI JNES.• JNEN()'¥ ) ERASE CONTIGUOUS SET pF SCREEN LINES ' 15too FNRFSQSC rna .IJNFS· ponyprs. vAa STG'· neFA.UI ys. HFI os. MA¥MINS 1 ASK FOR USER RESPONSE AFTER PROMPTING & VALIDATE .&' I 0 • 141 ------ROO !****************************************************************** & ! COMMON DECLAPATlaNS & 'lOO !***************••················································· & I OIMENSION DECLARATIO~S & 1000 !****************************************************************** ! MAIN PROGAAM LOGIC START \CFX • 11 X !SET CHANNEL M FOR TEXT DATA FILES \CKX "' l2X !SET CHANNEL M FOR KEYBOARD I/n \FII ES.ppNS ~ 1"• '•MtCHANG~ TO ntpJ.pNJ•• (N PRODUCTION t t;. \OPEN "KB:" AS FILE •CKX !OPEN UP THE KEYROAAD FILE t;. \DUMMYS • SYS( CHR5(11X) + CHHS( CKX ! ·~a_Qy~~_JyPE_A~EAD __ ~ I 1005 ! GIVE USER INSTRUCTIONS [F REQUESTED ******************************* t;. \PRINT MCKXt FNAREAS( OX 1; !CLEAR SC~EEN FNLOCS! 0502X li !SET CURSOR AT COL 5t LINE 2 ------'-":..>C"-'O=M_,P:.>ULT,__E,._,R._,S,._,.C-"I"-'E'-'N"-C~E._,A,_OIL!V--'I'--'S"-E"'-"-"1'-'E'--'N--'-'-T--'SLY,_S>LT•~""-~S I ON ,. I V.f:R S I ON$ j FNLOCS! 2203X ); OATESIOXII " "1 TIMES!OX)i I \PRS• •DO YOU WA~T INSTRUCTIONS" & \VALS~ "" & \OEFSz "" t;. \HELPS• "ENTER YES TO GET SET OF INSTRUCTIQNS1 NO TO SKIP THEM." & I 1010 RESPS• FNRESPSI 0522Xt PRso VALSo OEFSt HELPSt OX & !GET USERS R~SPONSE & \ON OPCOOEX GOTO 1010t 32000t 1005, 19200o 19200t 19200t 1015• 1020 & f HELP END BACK MINMAX DEFOK NOVAL YES NO & I 1015 PRINT MCKXo FNAREA5( OX I; !CLEAR SCREEN & \PRINT MCKXo FNLOCS( 3002% )i "INSTRUCTIONS"i & FNLOC5(0704XIi & "THIS IS A MENU-DRIVEN PROGRAM wHICH WILL ALLOW YOU TO RETRIEVE"i & \PRINT MCK·x, FNLOCSI 0705X )i & "ON-LINE INFORMATION WHICH WILL H~LP YOU ADVISE YOUR STUOENTS"I & CR;LF; TA816XJ; & "AS TO VARIOUS CURRICULA TO FOLLOWo COURSE PREREQUISITE STRUCTURESo•; & CBiLE; IAB(6%li & "COLLEGE/DEPARTMENT BEOUIBEMENTSt ETCETERA• PLUS STUOENT COURSE AND"I & CIHLEi TAI:l(6XI; ------~"~G~R~A~DuE~~~~~~~------~~ \PRINT MCKXt TA8(6Xl i & ·~OST QUESTIONS THAT ABE ASKED OF YOU WILL TYPICALLY REQUIRE YOU TO•; & CR;LF; TAAI6%J; & "ENTER A RESPONSE CONSISTING OF EITHER A NUMBER USUALLY REPRESeNTING"; & CRILF; TABI&%11 & •A SELECTION CHOICE FROM A MENU OP A YES (OR Yl OR A NO !OR Nl.•i & CloliLFi TAIH6XII & "NHEN IT IS DESIRED TO LOOK AT A STUDENT'S RECORDS, IT ~ILL ~E NEC-"1 & Cf.HI F; TAB!nlC, "ESSARY TO ENTER HIS 7-0IGIT FILE NUM8ERI PLUS A DATABASE ACCESs•; t;. CRILFI TABI6%li & "PASSwORP '"ILL HE REO!LJ..E!.ED TO LQOK AT A ST\JQENT •s RECORDS•" & \PI'IINT MCK%o TA1:1(6XII & •ALSOt EACH QUESTION CAN USUALLY 3E RESPONDED TO WITH 3 OTHER ALTERN-•1 & 142 _____._c..,e...,;u_;_-.rAUJ..o.S..Js..· ______----~- "ATlVES wHICH ARE: "I & CR;LFiLFi TA~C6XIi & ------'"'-----'"-'~llJ ______,..e..,x...,r_.r_s_y...mL.f__p _ _r!M__I._tf~QGHA~~LCR..i LE..l_!..<\B.l..fiX.U & SACK AETUR~S YUU TU THE PREVlUUS M~NU•i CAiLFiTAH(6Xlf & " AID OR HELP OISPLAYS EXTRA INFUAMATlON ON HUM TO ANSMEA"i & \PAS= "wANT TO CONTINUE" \VALSa "" F.~ "" \HELPS• "ENTER YES (OR Nl TO PROCEED TO ~ENUi NU COR Nl TO EXITo" & I t0\7 RESPS• FNRESPS( 0522;, pRs. VALS• DEFSy HE! P$_,..___..0'-""'--l,______...r:, !GET USERS RESPONSE & \ON OPCODEX GOTO 1017o 320D0t 1005, 19200• 19200o 19200o 1020, 32000 & HELP END BACK MINMAX OEFOK VALOK YES NO. & 1020 START PAINT OF MAIN MENU **************************************** .\CLOSE MCFX !CLOSE TEXT FILE INCASE RETURN & \PRINT .ttCKX, FNAREASI OX II !CLEAR SCREEN & ------~F~N~L~O~C~S~!L-~0~5~0~2~x~~~~~=---~!~S~E~T~~CUR$~·B-~~~S~·~LaAI~N~e~2.______u& "COMPUTER SCIENCE ADVISEMENT SYSTEM VERSION "I & VERSIONS; & MCKXo FNLQCSC 1403% ); "SELECTION MENU n; & DATESCOXII " •; TIMESCOXIl \PRINT ~CKXo FNLOCSI 0505X I~ NQO YOU WANT TO LOOK \PRINT MCKXo FNLOCSC1207XIi "II STUDENT'S RECORDS"; & \PRINT MCK%, FNLOCSI1208XIi & "21 COMPUTER SCIENCE BS & \PRINT MCKXo FNLOCS( 1209%) J .• ·. .· _, ..:.: ·. & '·•31 COMPUTER SCIENCE BS CONCENTRATED STUDIES" . ~- .. ·' & ______\,_,P"-'R"-"I.:..N ..L.I!QX• FNLOCS( 12\0X) i & "41 CSUN COURSE EQUIVALENCY WITH OTHER COLLEGES"; & \PRINT MCKX, FNLOCSC 1211Xli & "Sl CSUN COURSE EOUIVALENCY"i r:. \PRINT,MCKX• FNLOCSI1212XIi & "61 COMP SCIENCE ~lNOR REQUTREMENTS~ t 'PRINT !CKX, FIIILOCS! 1213% II c. "71 COMA SCIENCE GRAD CORE PREREQUISITE STRUCTURE" (, \PRINT AICKXt FNLOCSC 1214X I I & "B) COMP $C(fNCE & GENERAl \PRINT MCKlh FNLOCS( 1215% I I "9t EXIT PROGWAM" 1030 IDUMMYX"' CNTRLC ENA6LE CONTROL-C TRAPPING & & \QQS="PI FASf fNTFR SEI FCIION NUMBER" \VALS•"lo2•3t495o6o7,8o9" & ·_,DEF'II•"" & ------''UH:IJE"-1..1-"D'-"SU•IL:."'...EN.T.ER A SF! ECTTON N!IMHEQ BETWEEN 1 AND 8" 1050 RESP'!Ia FNRESPSC 0422Xt PR'IIo VALSt DEFSo HELPSo 0101% & \ON OPCODEX GOTO 1050, 32000• 1000o 1050, 1060o 19200o.l9200o 19200 & ' HELD END 8°CK M [NMA ¥ VALJ'K NOlJAI YES NO ' 1060 ON VAL! AESPS GOTO l200o 2000o 2500o 2BOOt 3000t 3500o ~OOOo 4500t & !GO TO APPROPRIATE TASK PROCESSING & I & 143 1200 I GO 'iiHNG IN STUDENT RECQ'lO RETRIEVAL CHAIN ********************** t t FNARE.J\..5.L_Q.X__,)_,;...____ .._. c.u:; A R SCRE~..______.r;. ------~'~D~LNT tCKSo FNLOCSI 2102% 1; !POSITION CURSO~ t "STUDENT INFORMATION RECORDS" t \FJLENUMS • •------" !MM~M~EPLACE wiTH LEGIT CODE t \STUDNAMES • •------~--" fMMMMREPLACE MITH LEGIT CODE t \PRINT MCKS, FNLOCSI 0404% II !POSITION CURSOR "STUDENT FILE M: "I \Pill NT MCKS, FNLOCSI 3104% H !POSITION CURSOR "NA"4 : ... STUDNAMES t .. ___ ., & \AQVISORS • ,__ t \PRINT MCKS, FNLOCSC 5604S H lPOS CUR & "ADVISOR: "J r. ADVISORS \COBOLSCOAES • "----" \FQRTRANSCOAES a "----" .& \CSQT,SCORES • K----" ., \CSQT,OATES a "M~/YY* & \Pr:IINT MCKS, FNLOCSI 0406% II IPOS CUR "PROFICIENCY TESTS•; FNLOCSI 0508% )i •cOBOL'"• COBOLSCORESt .&. FNLOCSI 0509S )I ·'· & "fORTRAN"• FORTRANSCOIIES; FNLOCSI 0510X II '& "CSOT"• CSQT,SCORES, CSQT,DATES l '& \PRS • 'WANT TO SEE STUOENT~S GRADE HISTORY• \VALS • ,.,. 'r. \DEFS • "" & \HELPS • "ENTER YES IYl TO LIST STUDENTS RECORDS; NO IN) TO "+ .t •RETURN TO MENU,• 1230 \RESPS• FNRESPSI 0422S,PRSoVALSoDEFs,HELPS,OX ) \ON OPCODEX ·GoTO 1230• 32000o 1020• 19200o 1250• 19200oo 1250• 1020 HELP END BACK MlNMAX VALOK NOVAL YES NO 1250 \pRINT MCIO\o FNAREASI OX I; !CLEAR SCB.E='------''- FNLOCSI 0123% )I •STUOE~TS RECORDS NOT AVAILABLE YET"I \SLEEP 5X tMMMMr:IEMOVE WHEN FINISHED \GOTO 1020 !MMMfXFER TIL REST QF CQDf IN PLACE &' & !CHAIN "HISTRY,TSK" & 2000 f PROCESS DISPLAY OF CQMP SCI BS CORE PREREQUISITE STRUCTURE ****** & t . - .. , \FILNAMS• "CSCORE.TXT" IQATA FILE HOLDING TEXT TO QISPLAY & \CURRENToFILES• ~lLES.PPNS + FILNAMS t fAOO ON [PPNl INFO TO FILENAME t 144 ----- __'UJPEN. -OJRHEN.'[..£.1 LU-f"~ J:.LP.llT J.S-F--LI..a--4!-C.FX ------£- !SET UP 8S CO~E TEXT DATA FILE'FOR & fl/0 ON CHANNEL ------~\~GuO~S~l~IB~~l~5,=5~0uOL-______~!~QwluS~P~L~AJY~T~F~X~LE_QN_sCR£El~------~~ \GOTO 2000 !REDO DISPLAY REQUEST 2500 ! PROCESS DISPLAY OF HS CQNCE[iT~ATFO STUDIES ********************** t:. I & \FTLNAMSz "CSCONC.TXT" & ------~\~C~U~R~R~ENT.FlLES• FILES.pPNS + FILNAMS & \OPEN CURRENT.FILES FOR INPUT AS FILE MCF~ & IGET OUR HANDS ON DATA FILE HOLDING & !5\JB Mf!y!J -AND- SE:TS OF CONC STIIQYS r. t & \GOSUB 15800 !GO DISPLAY SU~-ME:NU & TEXT & \GOTO 2500 fREDO DISPLAY ' 2800 !PROCESS CSUN COURSE EQUIVALENCY ~ITH OTHER COLLEGES ************~* \FILNAMS• "CSF-QUV.TXT" ! & \CURRENT.FILESa F~LES 0 PPN$ ~ FILNAM$. t & t \OPFN CURRENT.FILES FOR INPUT AS FILE MCF! ·' !GET OUT HANDS ON HEADER & DATA LINES & I & !DISPLAY TEXT FILE ON ,tREDO DISPLAY AGAIN .r ~- \FILNAMS• "CSCOUR.TXT" & \CURRENToFILES• FILES.PPNS + FTLNAMS & \OPEN CURRENT.FILES FOR INPUT AS FILE MCF% t ~~·~ t > ·. "'' ,,_. .·· !GET OUR HANDS ON HEADER &-.DATA .LINES & \Gosua 155oo .. 'l"DISPLAY. TEXT FILE ON SCREEN .·.::. \GOTO 3000 !DISPLAY IT AGAIN I ! pRQCESS t:· \FILNAMS• - \CURAENT.EILES• FILES.ppN, + FILNAMS \OPEN CURRENT.EILES FOR INPUT AS FILE MCF~ !GET OUR HANDS ON HEADER & DATA LINES & \GDS\18 15500 'QCSPIAY te:n FilE ON SCRE:EH C \GOTO 3500 DISPLAY AGAIN & & 4000 I PROCESS COMP SCI GRAO CORE PREREQUISITE STRUCTURE *************** I \fiiNAM5: "CSMAST.TXTP \CURRENTeFlLESa FILES.PPNS + FILNAMS . &; 'OPEN CURRENToFILES FOR INPUT AS FILE MCFX l &; ------~~~~~~iNnS-ON-HE~ \GOSUB 15500 IOISPLAY TEXT fiLE ON SCREEN & •son ~;~~~;~~~:;;;;::;;~;!;:~.?,X~~~~~-~:·~~:;.:~·::~ ...,::;:. .... ·:· ..· ·~ i \OPEN CUAAENT.FILES FOA INPUT AS FILE MCF! lGET HANDS ON TEXT DATA TO _DISPLAY 145 ------~·~w~~~~~~~s~nuoL------~IH~~.·~J-~~P~¥--~f------~ \GOTO 4500 !REDO DISPLAY AGAIN ~s~o~a~a----~·~c~.aacess Extr sE• ecTtnN *********L~~-·~·~••••~••••••*~*******~~ & \GOTO 32000 ! TERMINATE PROGRAM & 1~000 I FUNCTION DEFINlTIONS ******************************************* & & ------~·~-u-~-~-~-~-~~~~~-~---••••••••••••••••••••••••·.a~~~~·-···•••••·•·~-~ 15010 OFF FNLOCSI COLoLINEX & !GENERAL CURSOR POSITIONING ROUTINE & t INQ\IT PAihMETER IS ONE INTEGER COM- t · fSISTING OF COL MI01•801 * 100 PLUS ~ I LINE M I 0 1 -2 4 I & \CCLX a COL.LINE' I JOO% t, !EXTRACT COLU~N NUM & \LINEX a COL.LINEX - I 100X * COLX I & lfXTRACT LINE tfi/M £. \FNLOCS• CHRSI155~1 + "Y" + CHRSI LINEX + 31X I + CHRS( CCLX +31% • & ~POSITION CURSOR FOR TELERAY.CRT & 15030 !------& !THEN ERASE NUMLINES LINES. INPUT & !PARAM • 1 INTEGER CONSISTING OF & NUM~ER OF LINESIOI-241 a 100 + & STAIHING LINE NUM8ER(0t•24 I ; : · : & IF . INPUT PARM•O%, ERASE SCREEN'' ·> ~ &·· . ' & NUMLINESoLINF.NOX a OX THEN & TEMPS a CHRSI155XI+ "H"+ CHRSI155XI+ "J" & !ERASE ALL OF SCREEN & ELSE & NUMLINESX a NUMLINESoLlNENO% ' 100% & !GET OUR HANDS ON NUMaER OF LINES & \LINENOX • NUMLtNESoLlNENOX - ( lOOX * NUMLINESX I & !GET OUR HANDS ON STARTI~G LINE NO & \IE~PS a "" !NUlL ST91NG & \TE~PS • TEMPS~ FNLOC$1 100~ + LINENOX ~IX ) • CHRS(155X) ·~ "K" & FOR I~ a OX TO NUMLINES~ •lX & !CONSTRUCT SIRING TQ ERASE NUMLINES L !FOR TELERAY CRT 15050 FNAREAS a TEMPS !RETURN STRING ALREADY FOR PRINTING \FNEND lEND DEFINITION ! . 15100 ·------& DEF FNRESPS( COL.LINEX, PROMPTS, VALSTG~ 9 DEFAULTS, HELPS, & ICOLaLINE HOLDS COL*lOOX + LINE% & !FOR POSITION OF PROMPT & tPRQMDTS CONTAINS PROMPT TEXT & !VALSTGS CONTAINS LEGAL ITEMS THAT & !ANSWER CAN BE (SEPARATED BY ,) & 146 l..DEEA.UJ-U IS-IH£.....JJEFERED-1LAL..U.,·---- f.._ !HELP$ CONTAINS 1 LINE OF HELP & IMAXMJN IS ~AX & ~IN M CHARS OK & ------'''-'A,_,N,._,Sw_E~ S IS PJUte.QN S.I;,_B._IU!iR~_f.,.::_,oc______(L !OPCUOEX lS RETURNEif VALUE FOR GOres & & t 0 • UN E F__!l!E D E i'l P O ------~~=-~~K~------~'-4 • MIN•MAX ERROR & 5 TAKE DEFAULT/VALID RESP & ------~~6~~-~N~Q'-~V~A~L~ID.~.uN~!~F~A~I~L~Ic______~&~ 7 YES/Y & 8 NO/N & 'OPCQDEX • OX TO ILLEGAL VALUE & 'COLX • COLoLINEX I 100% & L I NE'J! ,. CO\.._..I,._~_N_EX • ( 1 Q..Q.."'·-"-.....,-="- -..1..------.,-----'"- ROW M & 'MAXX a MAXMINX I 100X MAXMIU~ M CHARS OK ~OR INPUT & ------~'~::MINX a MAXMINX ( 109% * MAX" !GET MINIMUM M CHAR OK FOR INPUT & 'PRINT tCK"t FNAREASI 0121% II. CLEAR LINE 21 & 'PRINT tCKX, FNAREAS( OlOOX + LINEX l; & !CLEAR FULL LINE 1ST THAT MSG ON 15105 PRINT tCKXo FNLOCS( COLoLINE" )I tPOSIT10N CURSOR AS SPECIFIED ·. & 'PRINT tCKXt PROMPTS! 'PRINT tCK"• •<"; DEFAULTS; ">"i IF LEN( DEFAULTS 'PRINT MCK"' "? "I ! PROMPTING ALL PQN,=-.,....-.------:-,------''-INPUT *CK"• ANSWERS . I'GET USER RESPONSE ... _-.-.· .. ·,ANSWERS • EDITS( ANSWERs.-':;sax l·! 2~ a NO BLANKSt-TABS ...... · · ..... , t !X a NO ESCtLFtCRtNUL,.~ I 32" • LOWER CASE •> UPPER '& !CLEAR LINES 23 & 24 FOR ERR MSGS & 'IF ANS•ERS • "HELP" OR ANSWERS a "AID" THEN PRINT tCKXt FNLOCst 0123" li HELPS' tGIYE THE USER 'OPCODE" a 1X & 'GOTO 15200 !SET RETURN CODE & GOTO CALLER & 15110 !CHECK RESPONSE FOR "END" ------·- IF ANSWER5 a "END" THEN opcnoex a 2% 'GOTO 15200 !SET RETURN CODE & GOTO CALLER 1 t CHECK FOR "BACK tt ------~'-"-,.______.._ IF ANSWERS a "AACKN T~EN & OPCODEX • 3!1: & ------''""G~ni.L.Lr... aL-tL,;5~2_,.ouo.______..;.•..:os .. e:...x.._~E r:. Gorn CAl 1 FR c 15125 !CHECK FOR DEFAULT BEING rAKEN -----·------·-- & IF I Fl\t' ANS«ERS ) a ox AND I EN I DEFAIII IS ) <> ns THEN ANSWERS • DEFAULTS tSET USER RESPONSE TO DEFAULT '& \OPCODEX • 5X ISET CODE FOR OK INPUT & \GOTO 15200 c I 15130 !CHECK RESPONSE ~OR MIN-MAX INPUT LENGTH i' . 147 \IF LEN! ANSWE~S l > M4XS 0~ LEN! 4NS~E~' ) < MIN~ rHEN ------~~~r~CK%• F~CjLL_U••~2~3~%L-~I~;------~~ "FIELD ~lOTH IS FRUM •; MIN%; " ro A MAX OF •; & ~AX%; " CMARACTE~s.•; & \GOTO 15200 !SET RETURN CODE & GOTO CALLER t _lc;~5.J.l..c:6u0.L---..I.lGu.OLJTLJ0.._.... ,-=5u.:l95 IF LEN! VA! SIGS I • "" 1 IE THERE rs NO Vll~U.O.llllll~...... :S~Tt.:G~-----...E~ t 15165 !CHECK RESPONSE FOR LEGALITY AGAINST VALIDATION STRING FOR STAQTpOS'J(, ~ I'J(, TO I fN I VALSTGS I STFP !~ \NEWPOSX ~ PUS! VALSTGS• "•"• STARTPOSX & \GOTO 15180 IF NE•POSX • 0% & !OUT OF COMMAS & NO MATCH EOUNp & \GOTO 15190 IF ANSWERS a SEGSIVALSTGSo STARTPOSXo NEWPOS%-1%1 & !HURRAYoo•A ~ATCH ~AS FOUND \STAPTPOS% a NEWPQS~ t HOPE FOR STMT NEXT ADOS 1 MORE \NEXT STARTPOSX ·t ~~O~--~G~O~T~O~~I;5~t~9~0~~I~F~A~N~S-=W~E~R~'~=·~·~M~I~D~S~(~V,,A~L~S~T~G~s~,~SwT~A~B~T~P~O~S~X~o~L~E~N~!~~V~A~L~SLT~G~s-·~)~L----···~&~ !CHECK FOR MATCH ON LAST ELEMENT OF & IVAL STRING SINCE NO MORE COMMAS & \PRINT NCK%, FNLOCSI 0123% IJ APLEASE & \PRINT MCK%o SEGSI VALSTGS1 l%1 59% J _ & \P~INT NCKX, SEGSl VALSTGS~60Xo 138% ); I~ LEN! VALSTGS ) >.59% & \DPCOOEX • b" \GOTO 15200 !SET RETUPN CODE & GOTO CALLER 15190 OPCOOE" • 5S [SUCCESSFUL NATCH <~:·:~·-•-c-:4·· - .&-. \GOTO 15200 BACK TO CALLER <>·.?····· .-.,.;.:. ·'.·:'''-"· :-\::-&. >''$.:-·'.•"· ..--;-- 15195 ANSWERS• "YES" OR ANSWERSa "Y" THEN OPCODE"= 7% \GOTO 15200 lYES FOUND ~ .-- •• : .• o'· ·;· :· 15197 IF ANS~ERs• ""NO" OR ANSwERS• 8 N" THEN . ·~··· & OPCOOE""' 811 & \GOTO 15200 !NO~AS FOUND !5196 PRINT MCKX, ENLOCS(0\23;1; "INVALID RESPONSE. PLEASE REENTE8·"' \GOTO 15105 !GO GET USER INPUT AGAIN t 15200 ENRESP$ a ANS~ERS ! RETURN RESPONSE AS EU.tim.O..,.Nu... ______..r._ \FNENO lEND FUNCTION DEFINITION & I !5500 ·------IFUNCTION TO DISPLAY ASCII FILE OF TEXT OATA \HC" a OX !SET HEADER LINE COUNTER 15520 LlNPUT NCFXo ONELINES !GET LINE OF TEXT 11 OF 5 HEADERS! & \fiDTO 15520 IF IFf:[( ONFI"TNFSe 2%) • "''" ,_ !BYPASS ANY COM~ENT LINES \HEAOER.SAVESCHC"l a ONELINES tSAVE HEAOER LINE \HCX • HC" + J~ !BUMP CNTR \GOTO 155~0 IF HCX < 5S lCHECK TO SAVE 5 LINES OF HEADER I 148 ------~ \PRINT MCKX, HEAOERoSAV~SIHC~I EO~ HCX • OX TU 4% ~ !DISPLAY 5 LIN~S HEAOER TO SCRE~N ~ ! I II< IT L.J NLC.QLI_N_LE R______------~\~L~C:-X~~=_JLX~------ 15540 \LINPUT MCFXo ONELI~ES !GET LINE OF rEXT \GOTO 155~0 lF LEFTI ONELlNE~o 2% ) • "!! ·~ ! BYpASS C: OMME NL..L..!l'it:_s___ -'------15543 PRINT MCKXo O~ELINES \LCX z LCX i" IX !BUMP .LINE CNTR ~ ______,,..,G..,O.,_T,_Q,.__.t..,.5_540 IF LC~ <~X"------~I._,Q,_N...... LL..LL~~E!:L.!i.AX OK & 15546 LINPUT MCFXo ONELlNES !GET TEXT INPUT \GOTO 15546 IF t...e..f.LL~~S~_,I~•=--"_.'~''-'-'------_.._ !SKIP THE COMMENT LINE& & \LCX • OX I ZERO OUT .LINE COUNTER t. f 15548 PRS a ~WANT TO SEE NEXT PAGE" t. \VALS • "" t. \DEF ,. "" \HELPS a "ENTER YES (VI TO DISPLAY NEXT PAGEl NO IN) TO RETURN "+ & "TO MENUo" .& 15550 RESPS• FNRESPS( 0522X 0 PRSoVALSoOEFSoHELPSoOX OPCOOEX GOTO 15550o 32000o 1020o 19200o 19200• HELP END BACK 15560 NO 15555 PRINT MCKXo FNAREASI OX li !CLEAR SCREEN & \PRINT MCKXo HEAOER.SAVESitXI FOR IX • 0 X TO 4X & ------...:.!-"O'-'I'-'S"'P"-'"Lo.=A:..:Yc__T~H'-'-'"E~!i.J•. J NE S OF HEADER t. 'tBACK TO PRINT~ SUMP LlNE CTR LOOP ~.~ '· ·-:~·~ L:; .. :>_: ...... ,. AGAIN" : '& t. " TO MENU." !5565 RESP!i• FNRESPJ( 0522%JPRSoVALSoOEFSoH~P~,_..L.... ______.._ !GET USER RESPONSE & \ON OPCOOEX GOTO 15565o 32000o I020o 19200o 1020, 19200o l5570o t. ______.______.HllE:JI~P _ __,E.....,.N...,D'-----"a,.A..,C'"'K~__.,MuiuN:<.~M ox DE F OK Nu.Q,_,V..,A..,!.___.y_.F;...oS.._ ____..._t 1020 _& I NO & 15570 CLOSE MCFX IRE~INO TEXT FILE BACK TO START & \RETURN !RESTART THE TEXT FILE DISPLAY t. 15800 t. ~------t. ______,tczF:.Jiu;!N.,._c.:Ll..tlJLIO_QL£Pl AY AScii Fl! E CQN.:U..l..llllNG.-SwlMENU r; TEXT DATA r. 15820 LINPUT MCF~, ONELINES IGET I LINE OF OArA FROM TEXT FILE & \fiOTO '5820 IF 'EFT I DNEl TNES· 2X' • "' '" !SKIP ANY COMMENT LINES 'GOTO 15820 IF LEFT( ONELINESo 6X I <>·"!MMIOO" & t SKIp \JNJ II REG IN SUBMFNII FOliNO t. !FIND SCREEN 00 & r & 0 . 149 -----~14-.~l..e~J-S.io--a.....SE~4---0I~l..-!Ne--~1-~~~--I--J \RESP$ a no• + RESPS RESPS ) <: 2~ ,., · .·. ~ \SEARCHS• RESPS !SAVE FOR POSSIBLE. RESEARCH '~~:+ffi(tci:: . -.,·; C.. tADO t.EADING ZERO IN ONLY 1 'DfGIT .·... & ISO WE'LL C4N GET A MATCH & 'GOTO 15930 IF LEFT( ONELINE$o 4~ ) • "!otMI" 15920 LlNPUf otCFXo ONELINE$ \GOTO 159Z0 IF LEFT( ONELINES• 4~ <> "tMMI" _,1'-'5"-9"-3=0__ ,_I,_F.-::S:.:E=..::ARCHS • SEGS( ONELINESo 5Xo 6" I THEN 15950 & ELSE 15920 & 15950 !PROCESS HEAQER & TEXT L \HC" :a OX IINIT LINE COUNTER 15960 LINPVT MCFXt ONELINE5 !GET 1 LIN 'GOTO 159&0 IF LEFTI ONELINESo 2" I • "!!" !SKIP COMMENTS & \IF LEFT( ONELINESo 4" I • "!otMI" THEN & PRINT •cK;, FNLOCSI 0123% ![ •MISSING HEADER INFO IN TEXT FILE "i & FILNAMS; "• SEEK AID" 'SLEEP 5X IGJVE USER CHANCE TO READ & \RETURN !LEI'S TRY AGAIN I 15965 •SAVE HEADER LilliE FOR LATER DISPLAY r. 'HClll • HC" + llll !BUMP LINE COUNTER & \GOTO 15960 IF HClll < 5lll !5 HEADER LINES MAX & 15970 PAINT otCKSt F~AREAS( Olll I; !CLEAR SCREEN & \PRINT otCKXt HEADER,SAVESCIXI FOR IX• OX TO 4" & p • 150 ------_ ____!OLSPLA.Y .tHE_ 5-L..l'·IE --HEADER.---·----4.: \L.C~'" OX !f"'IT TEXf L.INF. CUIJNTEQ 15980 L.lNPIJT MCF%o ONI::Ll"'E'S !GET 1 L.IIJE &: -----~\~Gu.OLI!.!0'-L.I.1.;;5~9R~J...Ef T'( ONEL..l NE 'S • 2~ I :a "~-----~-~IU£._(".0_1!M~~S-----&1 \!F LEFTI U~ELI~ES• 4" I '" "!MM!" TH~N &j GOTO 1F>020 &; ------4!~T~FuSLTL-cF~O~R~E~N~O~QE__~UtlLlST 'l"~~F-"_l~----~~ 159A3 PRINT MCK"' ONELINES ~ i \L.C" a LCll. + 1" !BUMP LINE CNTR &! ------~\~G~OuTuOL-~l~5~9~8~0~~l£F~L~C~"~<~L1~5A"~-----~:~o~N~L~Y~~1~~~~~~~0~K~------»'l 15986 !..INPUT MCF%, ONELINES !GET TEXT INPUT &! \GOTO 15986_lf LEFT( QNELINE'h 2" I a"!!'' &i \GOTO 16020 lF LEFT( ONELINESo 4% I • "IMM!" &! lEND OF LOGICAL FILE I 15990 PRS• "WANT TO SEE NEXT PAGE" \OEF'S • "" \HELPS ,. "ENTER 'I'ES IYI TQ DISPLAY NEXT DAG.E..LEI...S.i:: ENTER NQ (N)~-- 16000 RESPS= FNRESPS( 0522%oPRSoVALSoOEFSoHELPSo0%1 IGET USER RESPONSE \ON OPCODE% GOTO 16000o 320QO, 16010o 19200o 19200, 19200o 16015o HELP END BACK MINMAX VALOK NOVAL YES ,, 16020 &; 16010 CLOSE MCF% IBACI< PROCESSING . ' &ji ~----~--\~R~~~N~------~IuR~E~o~I~S~P~LaQA~Y~S~U~B~M~E~N~U~------~'; I 16015- PRINT MCK%o !BLANK SCREEN & MCK%o FOR IX a 0" TO 4% fr !DISPLAY THE 5 LINE HEADER '-._ ·. .- •. -. .-,_;- _,& --\LCX -. OX . ..lZERO· LINE CTR --- >.c·.;;:-c·---- ·.:_:·:·· c.. \GOTO 15983 tGD Q[SPt..Ay LINE AND BVM~CTR r; 16020 PRSa "•ANT TO SEE BEGINNING OF TEXT AGAIN" "' "" \OEFS• "" . \HELPS• "ENTER YES (Y) TO START LlST AGAIN; NO (NI TO"+ " RETURN TQ MENU." 16030 RESPS:o FNRESPS( 0522%oPRSoVALSoDEFSoHELPSoO% \ON OPCOQEX GOTO !6030o J?OOO, J?atg, tQ20Q• 1Q20Q. lQ?OOa HELP END ~ACK MINMAX DEFYES NOVA!.. l6040o 16010 16040 CLOSE MCF% r. \OPEN CURRENT,FILES FOR INPUT AS FILE MCFX r. \GDTO 15920 !START SEARCH FOR SPECIFIC TEXT (. ! t • ERROR TJJA.iiL.RROCE 55 r NG ***~#....&i..~&.'C.*-* ***** ****** ******* **** ' \RESUME 1030 IF ERR • 28X !CHECK FOR CDNTROL-C "' 'IF ERR • llX AND ERL • 15520 THEN . PRINT MCKX• FNAREAS( 0122X )I' ------~·~~~~~·~E~GA•' v enQM,~AwT~I~E~o~ruE~x~r~F~t~•~e~~•~"~'L------~4 FILNA~SI & •1, SEEK HELP,•I & 151 -----l------. & \.SLEEP 5~ !GIVE USE~ CHANCE TQ ~EAO & \~ESU~•t 1020 !BACK TO MAIN MEN~ & 19020 IF ERR = ll~ AND I ~RL a 15~40 OR ERL a 155~~ ITHEN & RESU~E 15~&0 !GO ASK QUESTION & 19100 IF E~RallX AND IERLat5820 OR EqLzl5A401 THEN & ------~~E_ERROg______PRINT FNLOCS(Ot2J~Ii "IMPROPERLY FORMATTED TEXT FILE. "+ & "EOF HIT ON "i FILNAMSi "• SEEK AIOo"i & \SLEEP 5X ''MAlT A BIT TO REA \CLOSE MCFX \RESU14E 1020 .!RETURN TO MAIN MENU 19110 IF ERR•tlX AND ERLa15920 THEN & PRINT MCKX• FNLOCSC0123XIi »SELECTION NO. "i RESPSi .& " NOT FOUND IN FILE "i FILNAM~i "• SEEK HELP.•; & \SLEEP 5X !PAUSE SO USER CAN READ & \CLOSE MCFX & ------~\~R~E~S~I~J~M~E~2~5~0~0------~!~G~O~~R~E~D~t~S~P~L~A~V SUBME~N~U~~A~G~A~l~N~--~------~& I 19120 IF ERW•llX ANO !ERLat5960 OR ERL•t5980 OR ERL•t59861 THEN & !EOF ERROR & PRINT MCKX• FNLOCSC0123XIi "ILLEGALLY FORMATTED TEXT FlL~•"J & . r. " EOF HIT ON "i FILNAMSi "• SEEK AIO.~t &. \SLEEP SX & \CLOSE •cFX \RESUME 2500 !GIVE SUSMENU ANOTHER CHANCE 191-30 ON· ERROR GOT!'! 0 !RESET NORMAL SYSTEM EPROR PROCESS···:.::.;',·- :>.. . ,;. . .. t 19200 !ERROR FROM ILLEGAL OPCODES- ~ORMA(LY SHOULDN'T HAPPEN & I & PRINT •cKXt FNLOCS( 0124XIJ "ILLEGAL FUNCTION RESPONSE. SEEK Ato.•; & \SLEEP 5X !PAUSE A 6tT TO ALLOW DISPLAY READ & \GOTO 1020 !EXIT PROGRAM ! 32000 !LOGICAL END PROGRAM ********************************************** & & ICLEAQ SCREEN LEFTOVERS & 32767 END APPENDIX F LOGIC FLOW: BATCH MODULES 1 • AVOlOO 2. AVOlOl 3. AV0200 4. AV0300 5. AV0400 6. AV0401 7. AV0500 152 153 F.l. Module AVOlOO Start AVOlOO l Open ADVISE-STUDENT-MASTER (File l) SCRATCH-FILE-1 (File 2), SCRATCH-FILF.-2 (File 3) SCRATCH-FILE-3 (File 4), SCRATCH-FILE-4 (File 5) CARD-IN (File 6), REPORT-OUT (File 7) DISK-STUDENT-MASTER (File 8), TEMP-ADVISE-HISTORY (File 9). Read in Control Card. Save REGIS Major Codes and Class Type of students to extract (Graduate/Undergraduate). l (A) Run Module SU04 to load File 8 from tape to disk. Module SU04 also loads from tape to disk the COURSE-MASTER-DISK file. Also each of these files should be used for input into Module AV0200 for concurrent runs. Read File 8 (Current CSUN DISK-STUDENT-MASTER) Extract and condense student records that roeet the selection criteria for Major (REGIS) codes and class type (if any) into two dtfferent output records. (B) Write the first record (ADVISE-STUDENT-MASTER Format) to File 2. Write the second record (ADVISE-STUDENT-HISTORY Format) to File 3. t Repeat steps (A) through (B) until file is processed. Rewind files. 154 (C) Execute Step (A) to setup File 8 to contain the Prior Semester DISK-STUDENT-MASTER File. (D) Read File 8, Read File 2, Read File 3 (E) Copy File 2 records to File 4 while also inserting any File 8 records (extracted and condensed) into File 4. Also, copy File 2 records to File 5 while also inserting any File 8 records (extracted and condensed) into File 5. Repeat Steps (D) through (E) until the complete file is processed (F) Using Step (C) logic, pass the "Prior Prior" sem ester DISK-STUDENT-MASTER against Files 4 and 5. This will produce: 1. ADVISE-STUDENT-MASTER File (for production) 2. TEMP-ADVISE-HISTORY file (for input to AV0101). Print report of control totals. t Go to Module AVOlOl. 155 F.2. Module AVOlOl Start AVOlOl 1 Open DISK-STUDENT-MASTER (File 10) TEMP-ADVISE-HISTORY (File 11) SCRATCH-FILE-S (File 12) REPORT-OUT (File 13) (A) Mount next DISK-STUDENT-MASTER tape. Run Module SU04 to load File 10 from tape to disk. l Read File 10 to get data for any semester's remaining~ data. Read File 11 and copy to File 12 while also inserting any records from File 10 into File 12 (after extracting and condensing records). (B) Next, rewind File 12 and treat as input File 11 and use File 2 (from AVOlOO) as the output file. Continue steps (A) through (B) watching the swapping of the SCRATCH-FILEs until all DISK-STUDENT-MASTER tapes have been processed and the final ADVISE STUDENT-HISTORY file is created. Print REPORT-OUT control totals. l Close files. l ' 156 F.3. Module AV0200 Open COURSE-MASTER-DISK File ADVISE-COURSE-MASTER File REPORT-OUT File. COURSE-MASTER-DISK File is a series of input files created by the SU04 tape-to-disk load module runs done at the beginning of Module AVOlOO. All of these files are read as input and then sorted in Year-Term (high-to-low) and Ticket-Number (low-to-high) order. This produces output file ADVISE-COURSE-MASTER. Write totals to REPORT-OUT. Print control totals in REPORT-OUT file. ! Close files. 157 F.4. Module AV0300 Start AV0300 Open TAPE-IN File ~ ADVISE-DEPARTMENT-STUDENT File REPORT-OUTl and REPORT-OUT2 File CARD-IN File. Read Control Card from CARD-IN file. Parameters will indicate if file update report is to be produced in File Number (F) or Name (N) order. Test-Date is saved. The Opscan Tape data is read in and then sorted as specified by either File Number or Name. The sorted file is then processed against the ADVISE-DEPARTMENT-STUDENT file and the scores are stored in the CSQT-SCORE field for each student with a score. If no student record is found in the ADVISE DEPARTMENT-STUDENT file for an existing CSQT score record an error record is written to the REPORT-OUTl file. As record processing proceeds a file update report is written to the REPORT-OUT2 file. REPORT-OUTl and REPORT-OUT2 are printed with~control totals. Close files. 158 F.5. Module AV0400 Start AV0400 J (A) Open ADVISE-STUDENT-MASTER (File 1) ADVISE-DEPARTMENT-STUDENT (File 2) OLD-DEPT-ARCHIVE (File 3) NEW-DEPT-ARCHIVE (File 4) OLD-TRANSFER-ARCHIVE (File 5) NEW-TRANSFER-ARCHIVE (File 6) ADVISE-TRANSFER (File 7) REPORT-DEPT (File 8) REPORT-TRANSFER (File 9). (B) Read Files 1 2 as needed. Read Files 3 5 as needed. Any record on File 2 that has no corresponding record (by File Number) on File 1 should be deleted from File 1 and merged (in sequence) with File 3 and written out to File 4. Write transaction history to File 8. i (C) Correspondingly, records on File 7 that do not have a match on File 1 can be deleted from File 7 after the data is merged (in sequence) with File 5 and written out to File 6. Write transaction history to File 9. f Continue archiving processes (B) through (C) until all file records are processed. Print report of transfer archive transactions and control totals (File 8). Print report of department archive transactions and control totals (File 9). Close files. 159 F.6 Module AV0401 Start AV0401 i (A) Open all files as specified in AV0400 file open step (A). (B) Read Files 1, 2, 3, 5, and 7 as needed. Any record on File 1 that has no corresponding record (by File Number) on File 2 should be matched against File 3 to see if there are any records on File 3 that can be transferred back to File 2. If there are some records, they are inserted into File 2 and not written out (deleted) to File 4 as it is being created from File 3. Also, write restore transaction pro cessing history to File 8. (C) Correspondingly, records on File 1 that have no match on File 7 should be matched against File 5 to see if there are any records on File 5 that can be transferred back to File 7. If there are some records, they are inserted into File 7 and are not written (deleted) to File 6 as it is being created from File 5. Also, write restore transaction processing history to File 9. Continue archive restore processes (B) through (C) until all file records are processed. t Print report of restore transfer transactions and control totals (File 9). Print report of restore department transactions and control totals (File 8). Close files. 160 F.7. Module AVOSOO Start AVOSOO l Open ADVISE-STUDENT-MASTER (File 1) ADVISE-DEPARTMENT-STUDENT (File 2) REPORT-OUT! and REPORT-OUT2 Files. (A) Read File 1 and File 2 as needed. (B) Attempt to match File 1 and File 2 records by File Number. If a record on File 1 has no match on File 2, write the File 1 record formatted to REPORT-OUTl File. If a record on File 2 has no match on File 1, write the File 2 record formatted to REPORT-OUT2 File. Continue processes (A) through (B) until all records are read and when done write control totals to REPORT-OUTl and REPORT-OUT2 Files. Print REPORT-OUT! and REPORT-OUT2 Files. Close files. APPENDIX G LOGIC FLOW: INTERACTIVE MODULES 1. AF0125 Faculty Advising Module a. AF0225 b. AF0325 c. AF0425 2. ADOlSO Department Maintenance Modules a. AD0250 b. AD0350 c. AD0450 d. AD0550 e. AD0650 1) AD650AS 2) AD650BS 3) AD650CS 4) AD650DS 5) AD650ES 6) AD650FS 7) AD650GS 8) AD650HS 161 INTERACTIVE FACULTY ADVISING MODULES G.l. Module AF0125 Start AF0125 {A) Ask User fort Password t Is Password Correct? No)ll' ~Yes Display "Invalid password. Reenter" (D) Display Selection Menu J Is Number oft Tries < 3? (B) User Enters Selection Yes/ \No ~ (A) Display {Entry 1 imit hit" Is Selection Valid? Yes/ \No User Logged Off Perform Selection Display "Invalid Choice. Reenter" End Program I Exit (B) Module AF0225 Student Records -co-n-ce-ntr-aTed Module AF0325 Studies List Any Other Module AF0425 Selection I-' 0'1 (\.) G.l.a. Module AF0~25 Start AF0225 Open AOVISE-(STUDENT-HISTO~Y),.- (COURSE-MAST£~). (STUDENT-MASTER) ___JQ_EPAillMENT -MASTER), (TRANS FER), and ( XSCHOOL-COfJE) t i 1es 1 (A) User Enters Student File Number or Name No7Input Either File Number or Na~es Display "Invalid Entry. l Yes \No (A)J I Search Files by Name Search Fi 1es by File Number t t Is Name Unique? Is Student on File? ------~- ~ ' ~s \Yes 7 (B) No/ (C) Display Student Name/File Number Display "Student jB) Display Submenu is not on file" 1 Ye7ated and Ask if Riqht On\ No f (D) User Enters Selection (A) (B) Bring up next Student t End of Studetts or File? Yes )s Selection \a~: \Yes i Process Selection Display "Invalid (C) Display "No function. Reenter" More Students" { (E) Exit (D) (I\)• DisplayY Data Dept Data -r- Ask: Want See lata l19~ Student Course No~- Yes - . - ( E) Close F·i les (D) er keturn to AF0125 (Di !Courses 1-' 0'1 w G.l.b. Module AF0325 Start AF0325 t Pass in Advise-Info (Type 2) "File Name" (from menu selection process) t {A) Open "Filename" Datafile f (B) Read Datafile t End of File? No/\Yes Yes ,, lh;' • ''~'"' \1 ~:"'' ::/'"''" "" ''\; .. (B) ~ Return to AF0125(D) Close Dataf1le Is This Submenu Start (A)t No (B) Display Desired Submenu (C) User Is Selection Legal? 7 vey \No Search File for Particular Display "Invalid choice. Reenter" Display Screen "! ## !nn" Requested ~ l (C) Now Proces~ Current Data in File Just Like in Module AF0425 at (D) to Display Header and Text Lines f-1 0"1 ,j:>. G.l.c. Module AF0425 Start AF0425 Pass 1n Advise-InfoI (Type 1) "File name" (from menu selection process) ~ (A) Open "F11 e Name" Oataf11 e l (B) Read Data File t End of File? No/- \ Yes Is this Conment (C) Yes No (B) (D) Read and Save Five Lines of Header Then Display Header t Read and Display up to 15 Test Lines Skipping and (!!)Comment Lines I Ask: Want to Continue to , ..; "'"' '""" Di' '1 '"\ No Display HP.ader Again (C) Ask: Review Text Again? f Yes I \No (D) Close Data File Close Files and + Return to AF0125(0) (A) ...... 0'\ lJ1 INTERACTIVE DEPARTMENT MAINTENANCE MODULES G.2. Module AD0150 Start AD0150 l (A) Ask User for Password - -- ~ Is Password Correct? ~---··-·-·---\~ No)? ~es Display "Invalid Password. Reenter" Display Main Selection Menu Is Number of Tr.i es > 3? (B) User Enters Se 1ect ion Yes \No I Is Select1onl Val1d? (A) Display "Entry limit. Hit" No Log User Off Display "Invalid entry. Reenter" Perform Selection ( B) End Program Exit Module AD0250 Transfer Course Maintenance Module AD0350 Advisor Master Maintenance Module AD0450 Student Master Maintenance Module AD0550 School Code Maintenance Module Ad0650 Print Ut il_i ty 1-' 0'1 0'1 G.2.a Module AU0250 Start AU0250 Open ADVISE-TRANSFERt File (A) Display Add/Change/Delete/Retrieve Screen (B) Enter Type of Functiont Wanted . F + . ,:T ---Va 11d ---unct1on?-\- ~ ~Yes Display "Invalid function. Reenter" Enter Data into Screen 1'1elds & VerHy (B)I Perform Selection r------1f~d Add H~cord to File ~) Delete Delete Record from File (A) ..------!Retrieve Retrieve and Display Record (A) ------,~hange File Number Term Delete +old record Exit Add new record Close Files (A) All Other Fields ' l + Return to Rewrite Record with Changes Module ADOISO(C) t (A) 1-' 0'1 -...J G.Z.b. llodule ADOJ~~ Start A003~0 Open ADVISE-DEPARTMENT-FACULTY and ADVISE -OEPARTM[NT -STUDENT (A) Display Add/Change/Delete/Retrieve Screen f (B) Enter Type of Function llanted · J Valid Function? ~;------~\~ "~ ~5 01 splay "Invalid Function. Reentl'r" Enter Oata Into Scrl'en Fields & Verify T l (B) Perform Selection Add Add Recor~ to File I (i) Change Code Delete Delete Old Retord on File I Add Hack New Record on File I t tlo T\~s Change !DC ODE In all I Affected File 2 records :B, \ 1e I ~ecord On 1y (!) er Students • 0 Els ... ~· .. r·-J "Cannot delete record" Initials Mv• sor Rttwri t~ Record wtt h Chan2es Auto-fi.il Balance (A) t (A) Retr!Pve Number Students Assigned e Record I . and uisp~ E•lt No changes perm! t ted T (A) f Close fill'S Give Error Message l + Rl'turn to (A) Module AOOISO(C) Note: Autobalanclng of student load Is done In this moduli'. See Appendix H. ,_. m 00 G.2.c. Module AD0450 Start A00450 t (A) Display Add/Change/Delete/P.etri~ve Screen t (B) Enter Type of function Wanted -- ~ Valid Function? No~-- ~es Display "Invalid function. Reenter" Enter Oata Into Screen Fields & Verff J (B) Perfonn Selection Add Add Record to File (A) Chanqe F! le Number Delete Delete Old Record Add Back New Record Ye:; OK to Oel \No J (A) Naf!ll.! Delete Record (B) FORTRAN-Prf COilOL-Prf l CSQT (A) R!'tr1eve Rewrite Record"with Changes .1\dvisor-10 Genf'ral RetrievP. Rl'cord (A) ~n ...... 0"1 1.0 G.2.d. Hodule AD0550 Start AD0550 l Open ADVISE-XSCIIOOL-CODE (F11e I) ADVISE-T~ANSf£R (File _2) (A) Display Add/Change/Oelete/P.etrievet Scrern (8) Enter Type ot Function Wanted Validl function? No ~------\ Yes Display • lnva It d function, Reenter• Enter Data Into Data F11!lds l (B) Perform Selection Add Dhp lay message +"Once record is added and used 1 t sho uld not be deleted Change Uelete OK t Ask: Are you Absolutely Sure no 1/o 7\,res Past Transfer Retords Use Th 1s School Code? (/, '\ ----~-- Verify i\le :es ·-- ..• ~ord to file I T No (1) DiSI Uelete File School Code Not Record Oi splay l.ssage l t "School code cannot be changed" (A)' (A) --, Retrieve (A) School Abhrev, School Name RetriL Record and IJi s play Rewrite F i I e I Retrd with Changes ...t lx it ClosP Files f Return to 11nnull' All0150(C) J-1 -....! 0 G.2.e. Module AD0650 Start AD0650 t Display Selection Menu t (A) User Enters Selection Is Selection Valid? No~-~-~------~--~ \ves Display "Invalid choice. Reenter" Perform Selection t (A) Submodule AD650AS List of All Advisors File Number Order List Submodule AD650BS of Students by Advisor Name Order List Submodule AD650CS of Students by Advisor File Number Order List of All Submodule AD65DDS Students in Department Database Name Order List of All Stu- Submodule AD650ES dents in Department Database List of All Data Course Submodule AD650FS Transfer File Info Submodule AD650GS List School Code File Submodule AD650HS List Department Info Text File Return to Module JI.Dl050(C) Exit ...... -...] ...... G.2.e.l Submodule AD650AS Start AD650AS f Open ADVISE-DEPARTMENT-FACULTY File Read File and Sort in Name Order and Create Formatted Report File l Ask: Print File Locally or Remotely? Local/ \Remote Give User Warning to Enter Banner Info Turn on Local Printer or Take Default Print Reportt File on Printer Send Report to Remotel Printer \ Close F1les.I t Return to Module AD0150(C) ...... --.J 1\.) G.2.e.c Submodule ADo50BS Start AD6501lS i Open ADVISE-DEPARTMENT-FACULTY (File 1) and ADVISE-DEPARTMENT-STUDENT (File 2) REPOHT-FILE l (A) User Enters Selection Criteria t Was "ALL" Entered? Ye~· -----\No (B) Read File and Sort in it File Number Does Faculty Initials or ID Code "''' ,,, ,,,,,, ,,,,,,,,, ,,,,, ,,,, ,.:;;::' ,,,,,,, ,,,,, ''""' '" ''''~,, Read File and Extract Display "Invalid Student records belonging value. Reenter" to indicated Advisor ~ (A) (C) Sort Extract File by File Number and Create Formatted Report File Ask: Print File Locally or Remotely? Local I -----··-\Remote Give User Warning to Enter Banner Info Turn on Local Printer or Take Default t Print Report File on Printer Send Report to Remote Printer \ Close Files Return to Modulet ADOlSO(Cj f-l -...J w G.2.e.3) Submodule AD650CS Start AD650CS f Open ADVISE-DEPARTMENT-FACULTY (File 1) and ADVISE-DEPARTMENT-STUDENT (File 2) REPORT-FILE f (A) User_!~ters Selection Criteria Was "ALL" Entered? Yey ------\No (B) Read File and Sort in it Name Order Does Faculty Initials or ID Code and Create Formatted Print Fi 1e Yes 7i fy against those found in F\ :: Read File and Extract Display "Invalid Student records be 1ongi ng va 1ue. Reenter" to indicated Advisor t (A) (C) Sort Extract File by Name and Create Formatted Report File Ask: Print File Locally ort Remotely? Loca 1 I \ Remote Give User Warning to Enter Banner Info Turn on local Printer or Take Default Print Report Fi 1e on Printer Send Report to Remotet Printer \ I Close Fi1 es ~ Return to Module AD0150(C) I-' -...] ~ G.2.e.4) Submodule AD650DS Start AD650DS { . The job described below is to be interactively SUBMITTED to run in batch mode (to release terminal} since it will likely be very long running l Open ADVISE-STUDENT-HISTORY, ADVISE-COURSE-MASTER, ADVISE-DEPARTMENT-STUDENT, ADVISE-STUDENT-MASTER, ADVISE-TRANSFER, ADVISE-DEPARTMENT-FACULTY, ADVISE-XSCHOOL-CODE files l (A) Read and interrogate all files to coalesce into one record per student, all student-related data and sort it by file number t Create a Formatted File of all data Send Report File to Remote Printer Closel Files f Return to Module AD0150(C} I-' -...) U1 G.2.e.5) Submodule AD650ES Start AD650ES The job described belowl is to be interactively SUBMITTED to run in batch mode (to release terminal) since it will likely be very long running i Open ADVISE-STUDENT-HISTORY, ADVISE-COURSE-MASTER, ADVISE-DEPARTMENT-STUDENT, ADVISE-STUDENT-MASTER, ADVISE-TRANSFER, ADVISE-DEPARTMENT-FACULTY, ADVISE-XSCHOOL-CODE files (A) Read and interrogate allf files to coalesce into one record per student, all student-related data and sort it by name f Create a Formatted Report File of all data Send Report File to Remote Printer Close Files t Return to Module AD0150(C) 1-' -...J 0'1 G.2.e.6) Submodule AD650FS Start AD650FS . ~ The job described below is to be interactively SUBMITTED to run in batch mode (to release terminal) since it could produce a lengthy report l Read the ADVISE-TRANSFER File and for matching file numbers extract Student Name from the ADVISE-STUDENT-MASTER File Since file is already in file number, year-term order, the records should just be formatted to a Report file Send Report File ro Remote Printer Close Files { Return to Module AD0150(C) ...... -..J -..J G.2.e.7) Submodule AD650GS Start AD650GS i Open ADVISE-XSCHOOL-CODE File ~ Read File in Code Order and Format to Report File Ask: Print File Locally or Remotely? Local/ _____ ------\Remote Give User Warning to Enter Banner Info Turn on Local Printer or Take Default + i Print Report File on Printer-\ Send Report to Remote Printer Close Files1 Return to Modulet AD0150(C) 1--' -..) 00 G.2.e.h) Submodule AD650HS Start AD650HS - t User Enters Selection Criteria Was 11 ALL 11 Entered? ~~------~----~\ Ye}f ~ No Open All Text Files (A) Display Subselection Menu Listing choices of Text Files Copy All Text lFiles to Print File. Separate by Record Mark for Page Eject l (B) User Enters tSelection Ask: Route to~emote Printer? Is Selection Valid? No ,1' "'Yes Yes/ \No Give User Warning to Ask for Banner Info Exit? Display 11 lnvalid Turn on the Local Printer or Take Default I \ selection. Reenter" 1 No. Yes f Displayt Print Send Report to Open Selected (C) (B) File Upon Screen Remote Printer Text File 1 l Close\ Files Display Upon Screen t (C) Return to Modulet AD0150(C) Close Text File (!) 1-' -...) \.0 APPENDIX H STUDENT TO FACULTY LOAD BALANCING CONSIDERATIONS Module AD0350 can contain procedures which make use of the Auto-Balance field in the Advise-Department Faculty file. The Auto-Balance field is used in conjunc tion with the number of students assigned to each faculty member. There are four areas where a balancing process will take place. These are described below. 1. A student is added to the Advise-Department-Student file. The process to add a student using Auto-Balance will be: a. Read into memory the Advise-Department-Faculty file omitting any instructors who have their AUTO-BALANCE-F field set to "M". Then sort this table on the NO-STUDENTS-ASSIGNED-F field in a low-to-high order. b. Assign student to the lowest faculty member on the list by adding one to the NO-STUDENTS ASSIGNED-FIELD-F and adding the advisor's code to the student's record in the Advise-Department Student file. 180 181 2. A student is deleted from the Advise-Department Student file. Alternatively the advisor code field in this file could be changed to spaces. If either of these are done, the NO-STUDENTS-ASSIGNED-F field in the Advise-Department-Faculty field of the affected faculty member should be decreased by one. No load balancing is attempted at this time so that other students will not be reassigned. This is to cause as few transfers of students as possible to keep the same student with the same faculty member. However, if the department wants load balancing it could be implemented as an option. 3. A faculty member is removed from the Advise Department-Faculty file because he has left the department (or he is no longer available for advising) so the AUTO-BALANCE-F field is set to "M" (or the record is deleted). a. There are two possibilities. One is the instruc tor's students are all to be assigned to a new advisor. If so, the only changes necessary would be to simply change the ADVISOR-IDCODE-D field in the Advise-Department-Student field for all stu dents with the old instructor's code. Also, the new instructor's NO-STUDENTS-ASSIGNED-F field in the Advise-Department-Faculty file should be set at the correct count. 182 b. If there is no new instructor to which students may be assigned, the students should be assigned to balance the number of students among the other faculty members. This can be done by: 1) Read into memory the Advise-Department Faculty file omitting any instructors who have their AUTO-BALANCE-F field set to "M". Then sort this table on the NO-STUDENTS ASSIGNED-FIELD in a low-to-high order. 2) Assign each student belonging to the old instructor to a new one by adding the student to the instructor with the lowest number of students. After each add, the students assigned counts must be checked so that in structors higher on the list will be assigned students if the one originally lower becomes higher. This process only distributes the excess students. 4. A faculty member is added to the list of advising faculty by either adding a new faculty record in the Advise-Department-Faculty file or an existing faculty member has his AUTO-BALANCE-F field set to "A". Stu dent load balancing may now be done by: a. Reading into memory the Advise-Department-Faculty file omitting any instructors who have their AUTO-BALANCE-F field set to "M". Then sort this 183 table on the NO-STUDENTS-ASSIGNED-FIELD in a high-to-low order. b. Now remove students from the faculty member with the highest number of students (first on the list) and assign them to the new advisor. After each transfer, the students assigned counts must be checked so that instructors next on the list will start losing students also if the one below has less students that the one preceding. This process only distributes the excess students. " . 184 ADDENDUM In section 3.5.1.2, which describes the operation of modules AVOlOO and AVOlOl, an error of omission occurred. The text should indicate, as shown in Figure 2, that con current processing of the Course~Disk-Master file with the corresponding Disk-Student-Master file is performed in order to create the Advise-Course-Master file at the end of the AVOlOl run.