COBOL Assignment 2 ("major COBOL program")

You need to have completed this assignment by Day 14 (Wednesday February 15th 2006) at 8:30am and you will show your program to me for evaluation purposes during the tutorial of Day 14 (or before). This assignment is marked out of 10 and counts 25 towards the final mark.

This assignment/program is intended to insure that you have a working knowledge of how to do major COBOL development tasks: maintaining a sequential file, maintaining an indexed file, sorting them and using sub-programs. This assignment is about adapting the programs given in the book to the input data set and coding conventions given in Assignment 1, and then combining these programs together. It does not require to do much "problem solving" in the sense of "algorithm design". This is why 1) a good part of the tutorials on sequential files, indexed files, sorts and sub-programs can be dedicated to it, and 2) it should not be too difficult to achieve.

This program should have five subprograms (which can at first be designed as independent "main" programs): a first one to "maintain" (i.e., add/delete/update records from/to) the sequential student master file, a second one to convert it into an indexed file, a third one to maintain this indexed file (with the same results as for the sequential file when given the same input transaction file), a fourth one to sort the sequential file into ascending sequence by student name, and a fifth one being the Assignment 1 program which generates a listing of the students. The main program should sequentially call these five subprograms (the program is not interactive: nothing should be asked to the user). Here are detail on the inputs and outputs of these five (sub)programs.

Calling subprograms is detailed in Chapter 11 (now seen on Day 7; thus, everything needed for this assignment will have been seen by the end of Day 7). A script to compile+link a program and its subprogram is given toward the end of my document on the Marist system. In this assignment, each subprogram is called only once and it may close all the files that it opens (the next subprogram will re-open them, if needed).

On the Marist mainframe system, the main program (the one calling the five subprograms) should be named "T2" (and be in your PROJECTA.COBOL directory). It must compile with a script named "CL2" in your PROJECTA.JCL directory. It must execute correctly with a script named "A2" in your PROJECTA.JCL directory. All the programs must be readable. The requirements (and examples of penalties) listed for Assignment 1 apply here too (this includes the naming conventions). In addition, you must:
- check the validity of the input data, and in the header of each subprogram, you must list all the kinds of data validation that you have implemented;
- provide a comment (use lowercases) before each subroutine of more than 10 lines (1 line of comment is sufficient if this comment does not include some pseudocode); (penalty of -0.25 each time this is forgotten);
- provide some pseudocode before each subroutine that has more than 20 lines (use a language such as C or Java but re-use the exact names the called sub-subroutines or subprograms and, if you use variables, use the exact names of the variables); (penalty of -0.25 each time this is forgotten);
- not duplicate code of more than 4 lines in several programs instead of using a subprogram or a file copy (-0.25 each time this happens).

Marking criteria (out of 10):
- first subprogram: 2.5;
- second subprogram: 1.25;
- third subprogram: 3;
- fourth subprogram: 1.25
- fifth subprogram: 0.5;
- main program: 1.5.

When you show me your program on Day 14 (or before), please give me a printed copy of it and its subprograms. To evaluate the working (and data validation) of your program, I'll give you new versions of TS2I and TS2T to run.


Addendum about data validation

Some examples are:
- checking that a student class level is 0, 1, 2 or 3;
- checking that a record to add does not already exist;
- checking the file status code after IO operations;
- using the Overflow clause, the On Size Error clause, etc.
In case of error, the program should print a message in an error file (use the transaction error files for all kinds of error) and, except for incorrect transactions, exit. Call a subroutine to do this error printing (so that this behavior for error handling can easily be changed by someone else, if necessary). To share this subroutine amongst programs, you can for example use a "copy" statement (you can use a subprogram too but this is more difficult since the error file is opened in another subprogram). A subroutine dedicated to checking the file status code and printing the relevant message is also necessary.

Put all your error messages in the error files; do not use "display" statements (I do not want to have to use the command line to run your program on the mainframe). I am aware that it is sometimes odd (e.g., if no file can be written on anymore, this message cannot be written on the error file; on the other hand, the system will tell you anyway; see also my previous email for the possibility of commenting out calls to the subroutine that displays file status errors). You may, if you wish, skip the checking of the file status for operations (open, write, close) on the error files.

For an error about a transaction, write the error message first, then the transaction to which it applies (it is preferable to put that transaction on another line to avoid constant horizontal scrolling but this is a very low priority requirement).

The code of the file status error printing subrroutine can be put into a file named "statusWrite.cpy" (on a laptop) and in this file the code can be something like
  *999-iSM-Status-write
    evaluate eSM-Status
      when 0 ...
      when 4 ... write eS.
      ...
    end-evaluate.
Then, in your (sub)programs, you can write:
    write oSR
    move oSR-status to eSM-Status
    copy "statusWrite.cpy".