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.
The first (sub)program should be the adaptation of the SEQ2000 program
(detailed in Chapter 13, and
here in lowercase to ease your adaptation).
The input/output files of SEQ2000 (given in C:\MCOBOL\BookPrograms\) are
OLDMAST (input master file of record length 70),
MNTTRAN (input transaction file of record length 61;
line-formated version here),
NEWMAST (output master file of record length 70), and
ERRTRAN2 (output error file of record length 61).
(See also this JCL script to execute SEQ2000; to compile and
link SEQ2000, CL can be easily modified).
On the mainframe, the adaptation of SEQ2000 should be named TSM2 ("T" and "2" for "Test/assignment 2", "SM" for "Sequential-file Management").
The virtual system names of the input/output files (i.e., the non-physical names used after "assign to" in the "select" statements) of TSM2 should be: TSM2I ("I" for "Input"; "S" for "Student-sequential-file") instead of OLDMAST, TSM2T ("T" for "Transaction") instead of MNTTRAN, TSM2O ("O" for "Output") instead of NEWMAST, and TSM2E ("E" for "Error") instead of ERRTRAN2.
The internal file names (i.e., the names used within TSM2 before "assign to" in a "select" statement) for these last 4 files should respectively be: iSM-InputStudentMasterFile, iST-StudentTransactionFile, oSM-OutputStudentMasterFile and eS-StudentErrorFile (thus, 'e' is a prefix too, in addition to 'i' and 'o').
The physical system names (on the mainframe) should in general be identical to the virtual system names. There are however 2 exceptions: 1) TS2I (the student sequential file) and TS2T (the transaction file) should be used instead of TSM2I and TSM2T since they are input to several programs (not just TSM2); 2) if there are several versions, the version number should be appended to all the version names except the first (e.g., TS2I, TS2I2, TS2I3, ..., TS2T, TS2T2, TS2T3, ..., TSM2O, TSM2O2, TSM2O3, ..., TSM2E, TSM2E2, TSM2E3). The JCL scripts make the connections between the physical system names and the physical virtual names.
Below is the record description of TS2T (record length: 44). For the content of TS2T, use this line-formated version or this not line-formated version of TSM2T. Since there are less fields in this record than in the master file, when you add a record, simply use spaces/zeros for the missing fields.
FD iST-StudentTransactionFile. 01 iST. 05 iST-Code pic x. 88 iST-Code-isForDelete value "1". 88 iST-Code-isForAdding value "2". 88 iST-Code-isForUpdating value "3". 05 iST-ID pic 9(09). 05 iST-Enrolment pic x. 05 iST-Name pic x(25). 05 iST-Level pic 9. 05 iST-Major pic xxxx. 05 iST-UnitsCompleted pic 999.
The second (sub)program should be the adaptation of the IND1000 program(detailed in Chapter 14; here in lowercase). The input/output files of IND1000 (given in C:\MCOBOL\BookPrograms\) are INVMASTS (input sequential master file of record length 70) and INVMASTI (output indexed master file of record length 70). On the mainframe, the adaptation of IND1000 should be named TIC2 ("IC" for "Indexed-file Creation"). The virtual system names of its input/output files should be: TIC2I instead of INVMASTS, TIC2IO ("IO" for "Input-Output") instead of INVMASTI, and TIC2E (in case errors needs to be printed). The internal file names should respectively be iSM-InputStudentMasterFile, oISM-IndexedStudentMasterFile and eS-IndexedStudentErrorFile. The physical system names should respectively be TS2I, TS2IO and TIC2E (plus version numbers if needed).
The third (sub)program should be the adaptation of the IND2000 program (detailed in Chapter 14; here in lowercase). Files related to IND2000 (given in C:\MCOBOL\BookPrograms\): INVMASTI (input-output indexed master file of record length 70), MNTTRAN (input transaction file of record length 61), ERRTRAN2 (output error file of record length 61). (Three examples of JCL scripts that compile+link and execute a program working on an indexed file are given at the end of my document on the Marist system). On the mainframe, the adaptation of IND2000 should be named: TIM2 ("IM" for "Indexed-file Management"). The virtual system names of its input/output files should be: TIM2IO instead of INVMAST, TIM2T instead of MNTTRAN, and TIM2E instead of ERRTRAN2. The internal file names should respectively be ioISM-IndexedStudentMasterFile, iST-StudentTransactionFile and eS-IndexedStudentErrorFile. The physical system names should respectively be: TS2IO, TS2T and TIM2E.
The fourth (sub)program is a simple sort on the student names (sorts are detailed in Chapter 16 but the edit-sort-and-update program named SRT1000 needs not be entirely re-used and adapted since no edit/update has to be done here). On the mainframe, this (sub)program should be named TSS2 ("SS" for "Sequential-file Sort"). The virtual system names of its input/output files should be: TSS2I, TSS2O and TSS2E (TSS2E is hardly useful here but use it anyway for putting things like file opening/reading/writing errors). The internal file names should respectively be iSM-StudentMasterFile, oSS-SortedStudentMasterFile and eSS-SortedStudentErrorFile. The physical system names should respectively be TSM2O (since the input of TSS2 is the output of TSM2), TSS2O and TSS2E.
The fifth program is TST1. When adapted to be a subprogram,
on the mainframe it should be named TSP2 ("P" for "Print") and the select
statements should then be:
select iSM-StudentMasterFile assign to TSP2I
select oSR-StudentReportFile assign to TSP2O
select eS-StudentErrorFile assign to TSP2E
The physical system names should respectively be TSS2O, TSP2O and TSP2E.
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.
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
when 0 ...
when 4 ... write eS.
Then, in your (sub)programs, you can write:
move oSR-status to eSM-Status