|
View previous topic :: View next topic
|
| Author |
Message |
hipatnaik
New User
Joined: 16 Aug 2005
Posts: 7
Location: NewJersey
|
|
|
|
Hi,
I am using an internal array of 600 bytes of length which occurs 1 to 999 times with Occurs Depending On max-size
1) Will the space be allocated for maximum occurances i.e. 600 * 999 even though max-size = 5
2) When the array is initialized, does it still take spaces?
Please let me know from the performance point of view if it's okay to have such size of internal array in COBOL.
Regards,
Biswa. |
|
| Back to top |
|
 |
dbzTHEdinosauer
Global Moderator
Joined: 20 Oct 2006
Posts: 6966
Location: porcelain throne
|
|
|
|
1. yes
2. depends on how you 'initialize' the COBOL INTERNAL TABLE.
performance?- what statements are you using to manipulate the COBOL Internal Table?
- what will you use instead?
arrays in COBOL are host variables for db2.
you can continue to use the wrong terminology, but it will yield less results on searches.
the following makes no sense:
| Quote: |
| an internal array of 600 bytes of length which occurs 1 to 999 times with Occurs Depending On max-size |
correctly stated would be:
a COBOL Internal Table with an item size of 600 bytes,
and an OCCURS clause that states 1 to 999.
the OCCURS DEPENDING ON (ODO) phrase is used for SEARCH and SEARCH ALL statements.
again, terminology is the key.
The COBOL Reference and the COBOL Programmers Guide have excellent descriptions/write-ups
about COBOL Internal Tables,
but say little about COBOL Internal ARRAYs - which actually don't exist.
there are COBOL Arrays and COBOL Internal Tables.
They are not the same. |
|
| Back to top |
|
|
Bill Woodger
Moderator Emeritus
Joined: 09 Mar 2011
Posts: 7309
Location: Inside the Matrix
|
|
|
|
To follow on from Dick, if you are worried about the limits for OCCURS, or anything else, check in your Language Reference.
Your particular table is far, far, away from any limits.
For performance and initialisation it depends on what you do, as Dick said. If it "took spaces before" it will still "take spaces". If you wanted to, you could set the whole table to space. |
|
| Back to top |
|
|
hipatnaik
New User
Joined: 16 Aug 2005
Posts: 7
Location: NewJersey
|
|
|
|
| Thanks guys for the quick help. Really appreciate it. |
|
| Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA
|
|
|
|
How are you loading this Internal Table? From a VSAM KSDS or ESDS file perhaps?
Bill |
|
| Back to top |
|
|
Anuj Dhawan
Superior Member
Joined: 22 Apr 2006
Posts: 6250
Location: Mumbai, India
|
|
|
|
If you define an OCCURS DEPENDING ON in Working-Storage (Term, Internal Table, actually suggests that - but I'll ask?), the amount of storage is always allocated to the maximum number specified in the "TO". On the other hand, Dynamic Allocation in Linkage allows you to allocate enough storage, based upon the amount needed/requested.
So if the assumption about WS is correct - COBOL is a compiled-language, so there is no way that it can have "dynamic arrays" for WS ODO. In other words, if the COBOL Internal Table is defined in Working-Storage with the ODO (occurs depending on) phrase, it will always be mapped to max potential size.
However, if the ODO is in FILE SECTION or LINKAGE SECTION. For FILE SECTION variables, the length of the data read/ written will be determined by the ODO - and this does leave plenty of potential for problems. In my small experience, I've used them very rarely. And in LINKAGE SECTION, the ODO should reflect the actual number of occurrences passed by the calling program.
Said that - I'm not very sure about the performance question now... |
|
| Back to top |
|
|
|
|
