In addition to Robert's points:
- You haven't, despite being asked at least twice, provided any information about what it is you want to achieve
- You have already been told how to aquire storage, using Language Environment HEAP storage
- Business solutions are not best served by deciding on a particular technical solution ahead of things and sticking to that come-what-may
It is unlikely that for you, or any other learner, making enormous Cobol tables is a good thing to do, or something that you will do frequently in your later career. When I started out, we had a much smaller limits to program size than there are today, and no direct support for acquiring extra storage (would have to be done via an Assembler sub-program), and the occasions where we considered techniques to do "big" things were rare and specialised.
To design your system/program you need to understand the business requirement and the data. You also have to take into account making your programs robust, understadable, flexible and maintainable.
You cannot just start with the idea "it'll be easy with everything in storage" and toss everything else away. It is a bad approach. By the time you have a task which requires "out of the ordinary" techniques, you will have at least several years experience, and perhaps many, and you would have ideas about how to do it yourself.
For a beginner, concentrate on writing good programs. The more time you spend on the design, the more open you keep your mind, the better the solution you arrive at will be. The program/system will be easier to understand, debug, test, prove, implement, support, amend and maintain - and it will serve the business requirement. All of these things are of the highest importance, and knowing how to make an enormous table just in case you genuinely need it in five years' time is of no importance.
If you were to describe to us what needs to be done, I am 99.99% certain that a huge table would not be the solution which best meets the above. If it happened to be so, I don't think it is a task for a beginner.
I'm not trying to say that the code is at all difficult, I'm saying that it is a bad solution. If the data is such that you cannot avoid a huge table, then I'm saying that the task is too complex itself (in that it is not open to a more usual solution) for a beginner.
"Business progamming" is very different from a university IT course. You are part of a team, and you do things the way everyone else does them. You do things the way the business requirment dictates, and according to the local "standards".
If you, or any other beginner, were to proceed with your expected solution don't be surprised if it is "bounced" at any sort of "code review" or even that Production Control or Production Support refuse to allow it to proceed.
So, no, I'm not going to show you how to do it. It is simple enough coding that you can achieve your aim through research. Other than a knowledge exercise, I hope you don't do it.
If you want some ideas about how to implement, let us know what you need to achieve, and the problems you are having envisaging how to do it.