You also don't need six seperate performs like that. Just one, and do it six times.
You don't have any code for testing if the page is full, to do the headings.
You don't have any code for either a partial table or a partial line. Even if not in the exercise, it is good practice, because in real life tables and things are often not completely full.
To find your problem next time, get a listing of the program, a pencil, and work through the code for any loops/tables writing down the values of any subscripts/indexes as they change. You'll find it easy to spot where you went wrong. Keep doing it that way, until you can do it "in your head", which means you find that when you are writing the code, you think about those things without thinking.
Can be good to start with pseudo-code, before writing a line of your program. Work through the pseudo-code with a pencil in the same way. You'll save yourself a lot of time, and even more when you get to do it "in your head".
With the pseudo-code approach, you have logic which "works" before writing a line of code. A tendency for new starters is, having written the code, to patch-up bad stuff rather than deleting it an starting again. Makes your code more difficult to understand. On a Mainframe, you'll be working in a team. Once you've implemented your code you may never see it again, Or not for months. Make it easy on others, and yourself, by making the code as clear as possible, not a patched-up mess (which can be fine for college-work, where someone just wants the result, but doesn't cut it in this business).