|
View previous topic :: View next topic
|
| Author |
Message |
Akriti Mishra
New User
Joined: 26 Mar 2020
Posts: 2
Location: India
|
|
|
|
| I have a COBOL batch program using large size array/table in it. What can be the alternatives to this array? The array size is going to increase in future? Or what can be an intelligent way to interact with tha day inside this array? |
|
| Back to top |
|
 |
Jose Mateo
Active User
Joined: 29 Oct 2010
Posts: 121
Location: Puerto Rico
|
|
|
|
| I had a similar problem where this program was reading a file and building an internal table with active accounts. The problem is that the input file was growing quickly and so often we had to increase the internal COBOL table. I agree this was a poor system design from the programmer who wrote the COBOL program. I resolved this issue by defining a external KSDS VSAM file and in the program I would read the input file and write the active accounts to the VSAM file. Once the input file reached EOF I would close the VSAM file and open it as input. Then I would search the VSAM file randomly by social security. |
|
| Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008
Posts: 8696
Location: Dubuque, Iowa, USA
|
|
|
|
Which version of Enterprise COBOL are you using? And what is a
| Quote: |
| large size array/table |
anyway? Current COBOL supports either 999,999,999 bytes for a single data item (if 32 bit) or 2,147,483,646 bytes (if 64 bit) so unless your large array/table is approaching these limits, you won't need to worry for a while.
The classic method, if you run out of memory for your data, is to write it to disk and VSAM works well for this as pointed out elsewhere. |
|
| Back to top |
|
|
Apoorva
New User
Joined: 28 Jan 2020
Posts: 49
Location: India
|
|
|
|
| Akriti Mishra wrote: |
| I have a COBOL batch program using large size array/table in it. What can be the alternatives to this array? The array size is going to increase in future? Or what can be an intelligent way to interact with tha day inside this array? |
As an alternative you could use a VSAM file to store the table data. With VSAM, you could store 4GB worth of data, and if the VSAM has "extended addressability" then it could go beyond 4GB. Though you get more space to store your data with VSAM, the tradeoff is processing time. Accessing VSAM involves I/Os, and hence will be slower than accessing data from the table.
If you want to deal with growing table size using internal tables itself, you could probably try using "linked lists" for tables. You could set aside 1st 4 bytes of your table to hold the pointer to the next table. As you load data to your table, and if the table can't hold anymore data, you could do a "GETMAIN" to allocate a new table, and store the new table address in the pointer of the 1st table (1st 4 bytes at the start of table). You can repeat this process until you are done loading the data. Finally if you have "n" tables built, 1st table will point to 2nd, 2nd will point to 3rd, .......... (n-1)th table points to nth table, and the pointer in the nth table will have just zeros which is an indication that it's the last table. |
|
| Back to top |
|
|
|
|
