IBM Mainframe Forum

Hi All,

Could anyone tell me how to implement Dynamic Array concept in a cobol programming manner.
I know using OCCURS DEPENDING ON we can implement but I need an example program.
Please help me out in this issue.

Thanks in Adv,
Regards,
Reebahs.

Depends what you mean by a "Dynamic Array".

Strictly, Cobol does not have Arrays. It has Tables.

A Table which uses Occurs Depending On is defined in the program by the Compiler has using the storage for the maxium value of the OCCURS specified. There is nothing "dynamic" about it in the sense that other languages use that word.

If you want to access an amount of storage which is only known at run-time, you'll need to use the HEAP processing from the Language Environment.

If you set out for us what your requirement is, we can provide better answers.

Hi BillyBoyo!

Situation is like I have to store the records comes from Input file but I don`t know how many records will come in the input file (No. Of records can be 1 lakh or 1 Million, or can be any number. We can`t say ) in a occurs table. How can I achieve this ?

Thanks in Adv,
Reebahs.

It is unusual that it is useful/necessary to store so many records in a Cobol table.

Usually, we design to avoid this happening.

So, setting aside for the moment that you have this as a solution, can you outline your processing for us? We will almost certainly be able to suggest other ways to do it. If we can't, we can make suggestions about how to implement huge tables.

BillyBoyo wrote:It is unusual that it is useful/necessary to store so many records in a Cobol table.

Usually, we design to avoid this happening.

So, setting aside for the moment that you have this as a solution, can you outline your processing for us? We will almost certainly be able to suggest other ways to do it. If we can't, we can make suggestions about how to implement huge tables.

Hi Billy !

Can you provide the solution for learners like me in both the cases..ie

Case 1 : If the user strictly wants to store so many records in Cobol Table

Case 2 : If the case 1 solution is not an effective one, what are the other suggestions available to implement huge tables

Thanks

sethurajan79, Google is your friend. Googling cobol occurs depending on returns 230,000 hits -- several of which on the first page are examples of using OCCURS DEPENDING ON. This is a HELP forum -- it is rare for actual code to be provided unless the person first posts the code they are having trouble with. Asking for code in the way you are doing is not a good thing -- responders on this forum are professionals and expect to be paid for delivering their work product (which is what you are asking for when you ask for code). Unless you're willing to pay for the code (typically rates run about 1000 US dollars or the equivalent in euros per day of coding), don't ask for code on this forum.

Find the Enterprise COBOL for z/OS Application Programming Reference manual for your release of COBOL and check out appendix B, which has the compiler limits. For example, a table cannot exceed 134,217,727 bytes (which is 128 MB minus one byte). It doesn't matter what you do, your table cannot exceed this size, period.

In addition to Robert's points:

1. You haven't, despite being asked at least twice, provided any information about what it is you want to achieve
2. You have already been told how to aquire storage, using Language Environment HEAP storage
3. 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.

Robert Sample wrote:sethurajan79, Google is your friend. Googling cobol occurs depending on returns 230,000 hits -- several of which on the first page are examples of using OCCURS DEPENDING ON. This is a HELP forum -- it is rare for actual code to be provided unless the person first posts the code they are having trouble with. Asking for code in the way you are doing is not a good thing -- responders on this forum are professionals and expect to be paid for delivering their work product (which is what you are asking for when you ask for code). Unless you're willing to pay for the code (typically rates run about 1000 US dollars or the equivalent in euros per day of coding), don't ask for code on this forum.

Sir,

I am not asking you to code me the solution I need. I am just asking the ideas to get clarified. As you have vast experience and would had provided lot of solutions compared to learners like me, it is always good to seek guidance rather than blindly googling it and following a link and I feel to seek information at the right links is more important than to search google and browse links without any focus.

Find the Enterprise COBOL for z/OS Application Programming Reference manual for your release of COBOL and check out appendix B, which has the compiler limits. For example, a table cannot exceed 134,217,727 bytes (which is 128 MB minus one byte). It doesn't matter what you do, your table cannot exceed this size, period.

This experience and guidance that you can provide are required for us and help for learners like me. We don't need code and I will not ask you to post code without me making any attempts. I will ask the solutions only if I had tried something in coding and will ask the idea to point out the mistakes I am doing. As you have experience and knowledge, you know where to target the information whether we are less focused and less knowledgeable but we are in the process of gaining knowledge. As you suggested the source, I can now go ahead and proceed to seek required information.

BillyBoyo wrote:In addition to Robert's points:

1. You haven't, despite being asked at least twice, provided any information about what it is you want to achieve
2. You have already been told how to aquire storage, using Language Environment HEAP storage
3. Business solutions are not best served by deciding on a particular technical solution ahead of things and sticking to that come-what-may

First of all, thanks for taking your time to reply.

Infact being a learner , I do not know how the solution look like or to be honest do not know what is heap storage and how it used but now I got the term heap proceesing / heap storage and now I will proceed to seek information regarding this in forums

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.

Thanks for the suggestions and surely will try as much as programs as possible to gain knowledge.

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.

I have just asked the ideas and will get back to this once I work a lot with programs. Thanks

Hi,

In addition to sethurajan79 points,

We are not asking for the whole code. We are looking for the pseudo logic to implement the thing from U like experienced professionals.

Hope you understand....