COBOL Curriculum 2000:
Trilogy
presented at the
Sixth COBOL on Campus Symposium
Wednesday May 20, 1998
at the
Walt Disney Dolphin Hotel
Orlando, Florida
By
Ronald J. Kizior
Email:
Loyola University Chicago
Chicago, IL
Alden C. Lorents
Email:
Northern Arizona University
Flagstaff, AZ
Will Price
Email:
California State University, Hayward
Object-Z Systems, Orinda, CA
COBOL Curriculum 2000: Trilogy
Presented by
Ronald J. Kizior
Email:
Loyola University Chicago
Chicago, IL
Alden C. Lorents
Email:
Northern Arizona University
Flagstaff, AZ
Will Price
Email:
California State University, Hayward
Object-Z Systems, Orinda, CA
Part I - Future Curriculum Possibilities -Kizior
There has been a certain revitalization and interest in the Cobol language recently, due in some respects to the (Y2K) year-2000 crisis. There have been some statements made that attributed this crisis to COBOL itself. It’s all Cobol’s fault. This revitalized interest in COBOL has manifested itself by increased enrollment in COBOL programming classes, and an increased number of calls from head hunters inquiring about our current or past Cobol students. In less than 592 days, that crisis will come and go, and then what happens to the demand for COBOL programmers. Well, the fact is that we in academia should start to think about the next decade. In particular what approach should be taken in regard to teaching COBOL and what should the Cobol curriculum consist of? As academics, we have a responsibility to our customers, namely “our students”. Are we going to prepare them properly for the future? And how should that preparation be carried out? Will COBOL be as viable in the future as it was in the past? Do we change from structured COBOL to Object Oriented COBOL? Remember, we changed from original COBOL to Structured COBOL, and we are all here as living proof, that COBOL has survived that transformation and has flourished. Can it remain viable under a different form in the future? These are all questions that to which we would all like answers.
In light of these questions, how do we properly prepare our students for the future? Remember what we teach today, assuming our students at the time are juniors, won’t take affect until two years or more from now. How do we properly prepare them? Do we prepare them just enough so they can get their first job, or do we prepare them, so they can get not only their first job, but also the second, third and possibly even their fourth job? Do we concern ourselves about the short run or the long run? Do we prepare our students just to get their first job, or do we empower them to be able to do a good job now as well as to be able to change and adapt to any environmental or methodological changes that may occur in the future. In trying to answer these questions, my concern here today will focus on what type of curriculum for COBOL should be carried out in the future? There are numerous factors that can affect the content of the curriculum, and their affect is not static nor a stand alone, but a very dynamic. Because it is a dynamic situation, it is hard at times to look only at one factor. It seems that when we discuss a factor, we shortly realize that it is related to another factor, and that in turn is still related to another.
The first of these factors that I would like to touch upon is that of accreditation. Those institutions that are accredited by the AACSB or various regional accrediting agencies, such as North Central, or the Southern Association have to be concerned about the guidelines that are set up by these accrediting agencies. Most educational institutions are very concerned about their accreditation rating, and usually take very precise steps to be sure that it is operating according to these guidelines. One of the parameters that appears to vary from institution to institution is the number of courses that make up a major field or concentration. A major in one institution could be a minimum of 15 credit hours or five course, while in others it could be a maximum of 24 credit hours or 8 courses.
A second parameter used by some schools relates to a percentage guideline. Some institutions have a percentage requirement for three of four major groupings. One example might require that 54% be Liberal Art courses, 31% business core courses, and 13% for courses in your concentration, and possibly 16% as free electives. Another institution might have a mix, such as: 46% for A&S, 38% Business Core, and CIS major at 16% ( seven course concentration). A third university has 37% for university requirements, 35% for business requirements, and 28% ( 6 courses) for CIS concentration. Which one is the best? Why the difference?
Let’s take a closer in-depth analysis of one situation. What should an institution do which has developed various functional areas as concentrations under the policy of requiring only five courses for that major. Let’s take the case of an I.S. concentration made up of five courses in which one of the courses is the Cobol programming course. My concern here is how does one keep up-to-date and attempt to introduce, for instance, Object Oriented COBOL into the curriculum, if there are only five courses for the concentration?
There are a couple of ways that one could proceed. The first and most obvious reply that one might have, is why don’t we just expand the five-course requirement to six courses. This would definitely be the easiest, provided that the institution can stay within the guideline percentages of liberal arts, business core, and area of concentration. From a faculty point of view this would definitely be the easiest. It might be a little harder to convince the dean, or even a campus wide faculty committee on curriculum. The more layers that an institution has approving such changes, the harder it might be to get it approved.
A second possible solution, and one that leads to further questions and discussion is the situation of attempting to replace the current Structured COBOL course with an Object Oriented COBOL course. Is this a good approach? This alternative brings up several other intriguing questions. Do the students have the ability to grasp Objected Oriented COBOL as their first programming language? If we start with O-O COBOL, does this imply that we are leaving out the structure methodology? Do we want to do this? I also have another concern and that is, should students first be exposed to O-O general concepts before being introduced to O-O Cobol? And if you feel that this is necessary, remember that this will require more classroom time and take time away from O-O syntax and program development time.
As suggested in Figure 1 below, there seems to be three possible alternatives that an institution could take, but it is not exhaustive. Under the first alternative, a question arises as to whether there would be a sufficient amount of time to cover all of the structured Cobol topics in only
one semester, since most current programs have a two semester course sequence. Personally, I rather doubt that it would-be possible.
Secondly, this alternative would require that this additional course would have to be approved by the curriculum committee. If we add the course, do we add it as an elective course and do not make it a requirement of the IS concentration?
The second alternative adds two additional courses to the existing curriculum. If one course is hard to get approved imagine what it is going to take to get two new courses approved. In adding these two courses, the curriculum would now fully explain object oriented concepts and advanced O-O Cobol programming in the process. Under alternative three the institution decides to make a very definitive break away from structured methodology and fully endorse the O-O format. Are institutions ready, willing and able to do this?
There is still another factor, which could have some influence on which approach should be pursued, and that is the “market factor.” What is industry currently using, and what are they planning to use within the next five or ten years.
What if industry is slow and hesitant about using the O-O approach and continues to develop systems in a structured way? Are we doing a disservice by attempting to teach our students O-O concepts, which might not be used for some 20 years or more? Or do we continue to use and teach structured methodology in order to make the student marketable now? This is not an easy question and it is even harder to come up with an answer.
An open discussion of these views, and an expression of the pro’s and con’s of each alternative is important, so that a viable curriculum can be developed to enhance the education and marketability of our customer’s, “ Our Students”.
Future Future Future
Current Alternative 1 Alternative 2 Alternative 3
COBOL I COBOL I(Structure) COBOL I ( Structure) COBOL I (O-O)
COBOL II COBOL II(O-O) O-O Concepts COBOL II (Advanced O-O)
COBOL II (O-O)
COBOL III (Advanced O-O)
Figure 1
______________________________________________________________________________________
Part II - Objectives of teaching any programming course - Lorents
We are in the business of education and not in the business of training. When we educate a student, that student is able to adapt and apply his or her knowledge to a variety of new problems and changing environments. Training is the process of learning a new tool such as a new programming language. Education is a process of building a foundation of concepts, frameworks, and thought patterns that enable the student to solve problems. Tools are used to enhance and leverage the problem solving process. We use tools in our curriculum to assist us in the process of building foundations and reinforcing concepts. Tools are also important in helping the student land that first job.
A primary objective of any programming course is to learn concepts, and how these concepts are applied in various problem-solving environments. There are hundreds of concepts that are taught as a part of the programming courses in most CIS programs. The following list is an example of some of these concepts.
Concepts Related to Structure
Constructs: sequence, decision, and iteration.
Program component interaction.
Sub components, Sub programs
Component communication
Linkages and Switches
Program structure and standards
Concepts Related to Data
Data structures, record structures, file structures
VSAM file structures and indexing concepts
Relative file structures and pointer structures
I/O considerations for various file organizations
Data representation, signs, types, storage space
Database and embedded SQL considerations
Downloading and uploading (ASCII, EBCDIC)
Data flow and data manipulation
Subscripting, indexing, table concepts
Concepts Related to OO Programming
Object constructs and concepts
Polymorphism, Inheritance, Encapsulation, Handles Collection objects
Building and using objects
Class libraries
Concepts Related to Building Applications
Compiling, testing, online debugging
Test suites, test generators
Program maintenance, analyzers, versioning
Linking and building executables
Copy libraries
Documentation
Concepts Related to a User Interface
Window design, window components
Window/program interface considerations
Event-driven programming
Client/Server components
Browser and CGI programming
Buffer and paging related issues
The underlying concepts are almost the same for all languages. The basic code structures are very similar across languages. An IF structure is an IF structure, and a loop is a loop. There is some difference in the syntax, but the amount of time spent in any programming course on syntax is minimal. Languages vary in features that make it easier to do certain operations. For example COBOL has good file handling and data formatting ability. Visual Basic has good event driven ability.
There is a misconception that if a language is new, it is cutting edge and up to date, and if a language is old, it is out of date. We need to educate students, counselors, and even some in industry that the focus of our CIS curriculum is on building the fundamental concepts and foundations. The selection of tools we use to do this is not the major focus.
At times, I think we have a tendency to let tools drive the content of our curriculum. When we started teaching Visual Basic instead of Basic, we introduced a lot of new programming concepts dealing with event driven programming and visual interfaces. This is okay as long as we recognize that we have pushed out concepts that we use to spend time on, and that we consciously make this decision. At NAU, we have a programming sequence that includes Visual Basic, COBOL, and OO COBOL. We do not use tool names in our course names or descriptions. We use generic course names such as Application Programming I, II and III. We can at any time change the OO COBOL to Java, or to a combination of OO COBOL and Java. We have developed models similar to Will Price’s Room Model in both OO COBOL and Java where the JAVA program works just like the COBOL program . We can teach OO with either Java or OO COBOL, but the issue is what other concepts get driven from the course if we switched the course to Java. An alternative is to teach Java as part of a WEB based development course.
Another dimension that has a bearing on our choice of tools is the market that we are trying to prepare our students for. At NAU, we have traditionally targeted the larger organizations that have large mainframes and COBOL based enterprise wide systems. The COBOL base in most of these organizations is not changing very much. Another interesting factor is that there is not a lot of activity among large organizations to use OO development methodologies to replace these large legacy systems. There is some OO development on the client side and in smaller departmental type systems. The lack of OO interest at this time relative to the legacy systems may partially be a result of all the effort going into Y2K upgrading.
COBOL Directions for Future CIS Curriculums.
At NAU, we plan to continue with COBOL in the CIS curriculum as long as there continues to be a large base of COBOL used in the larger organizations. One of our recent candidates interviewing for a position stated that he felt COBOL was the best language to learn the beginning concepts of programming.
Many programs use COBOL in their first programming course. We will probably change our first programming course to COBOL and switch Visual Basic to a more advanced level. We will probably not introduce OO in our first programming course. Dialog Systems will be used to build windows. Control breaks and sequential logic will be dropped from this course. We will cover VSAM and related data storage concepts in depth. We will also cover sub programs, and all the fundamentals of structure, testing, online debugging, and documentation.