View previous topic :: View next topic
|
Author |
Message |
jdeeponline
New User
Joined: 08 Sep 2009 Posts: 27 Location: Charlotte
|
|
|
|
Hi,
Is it possible to define a dynamic COBOL array without giving a fixed upper value.
The "OCCURS X TIMES" will limit the array to occur for the maximum of X times and not beyond. Is there a way out of this? |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
COBOL is a compiled language. At the time your program is compiled, the maximum size of the array must be known so the compiler can handle the array appropriately. If you go to the COBOL Language Reference manual (link at the top of the page), and read the syntax diagram for the OCCURS DEPENDING ON clause you will find that the upper limit is mandatory and must be an integer value.
There is no possibility of having a COBOL array where the upper limit of the number occurrences is not known at compile time.
Perhaps if you told us what you need to accomplish, rather than deciding in advance how you want to accomplish it, we can suggest some alternatives. |
|
Back to top |
|
|
jdeeponline
New User
Joined: 08 Sep 2009 Posts: 27 Location: Charlotte
|
|
|
|
Thanks.
My requirement is to map certain table values using a cursor to this COBOL array. This is part of an online transaction.
However, there is a possibility that the table may get loaded every quarter and hence, arises a need to change the upper limit of the COBOL ARRAY evry time.
Giving a very high upper limit may hamper the memory allocated as I believe, even for DYNAMIC array the memory is allocated for the entire size irrespective of the "depending on" clause |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
However, there is a possibility that the table may get loaded every quarter and hence, arises a need to change the upper limit of the COBOL ARRAY evry time. |
Part of that quarterly activity might be to modify the code accordingly and promote the new version of the code. . .
Personally, i believe that loading an entire table into an array for online processing is a complete waste of resources. . . |
|
Back to top |
|
|
jdeeponline
New User
Joined: 08 Sep 2009 Posts: 27 Location: Charlotte
|
|
|
|
Yes this is the concern. That we will have to modify the code every single time.
And loading the table to Array happens only once in a single thread of transactions and not for every transactions.
Appreciate all your responses. Thank you. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Because you use the term "Transaction" (and CICS is not mentioned) I'm not sure whether you're talking about CICS or Batch?
If Batch, what type of file, QSAM, VSAM, etc?
What is the highest potential number of records (a SWAG will do) and what's the LRECL?
Bill |
|
Back to top |
|
|
jdeeponline
New User
Joined: 08 Sep 2009 Posts: 27 Location: Charlotte
|
|
|
|
Its CICS transaction wherein the backend table values are fetched using a Cobol DB2 prog.
The tables we intend to load have at an average 500 records with an Avge length of 150. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
I'm not a DB2 Application guy, so I'll ask whether there's any way to query DB2 (or, take a SWAG) ahead of time and get the number of associated records for the internal array?
If this is possible, then there's an easy solution.
Bill |
|
Back to top |
|
|
jdeeponline
New User
Joined: 08 Sep 2009 Posts: 27 Location: Charlotte
|
|
|
|
We have the number of records already. We have set the upper limit ffor the COBOL array accordingly. However, there is a probability that this may increase on a monthly or quarterly basis. This would result in change in the Array definition.
So the concern is if we could avoid this change of code evry time. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
OK, here's what I think will work.
01) Define the following in LINKAGE -
Code: |
01 LS-DYNAMIC-TABLE-REC.
03 LS-DYNAMIC-NBR-RECS PIC S9(08) COMP.
03 LS-DYNAMIC-REC PIC X(16777211).
|
02) In WS, define -
Code: |
01 WS-DYNAMIC-TABLE-ELEMENTS.
03 WS-DYNAMIC-POINTER POINTER VALUE NULL.
03 WS-DYNAMIC-NBR-RECS PIC S9(08) COMP.
03 WS-DYNAMIC-REC-KTR PIC S9(08) COMP VALUE ZERO.
03 WS-DYNAMIC-FLENGTH PIC S9(08) COMP.
03 WS-DYNAMIC-NEXT-POS PIC S9(08) COMP VALUE 1.
03 WS-DYNAMIC-INITIMG PIC X(01) VALUE LOW-VALUE.
03 WS-DYNAMIC-REC-LGTH PIC S9(08) COMP VALUE 150.
|
03) Then, logic in PROCEDURE -
Code: |
COMPUTE WS-DYNAMIC-FLENGTH = (WS-DYNAMIC-NBR-RECS * WS-DYNAMIC-REC-LGTH).
ADD LENGTH OF LS-DYNAMIC-NBR-RECS TO WS-DYNAMIC-FLENGTH.
EXEC CICS GETMAIN
SET (WS-DYNAMIC-POINTER)
FLENGTH(WS-DYNAMIC-FLENGTH)
INITIMG(WS-DYNAMIC-INITIMG)
NOHANDLE
END-EXEC.
IF EIBRESP NOT = DFHRESP(NORMAL)
PERFORM GETMAIN-ERROR-RTN
GO TO END-OF-PROGRAM
END-IF.
SET ADDRESS OF LS-DYNAMIC-TABLE-REC TO WS-DYNAMIC-POINTER.
MOVE WS-DYNAMIC-NBR-RECS TO LS-DYNAMIC-NBR-RECS.
|
At this point, beginning at byte-01 of LS-DYNAMIC-REC, using the length value in WS-DYNAMIC-REC-LGTH, move each record from DB2 into LS-DYNAMIC-REC, via reference modification, adding WS-DYNAMIC-REC-LGTH to WS-DYNAMIC-NEXT-POS, for the "next" record and bumping WS-DYNAMIC-REC-KTR by 1, until WS-DYNAMIC-REC-KTR exceeds the value in WS-DYNAMIC-NBR-RECS.
FWIW, 16MB-1 (16777215) is the largest "01" storage-area you can define.
It is assumed that you've populated WS-DYNAMIC-NBR-RECS beforehand with the actual number of records (from DB2) you'll be loading.
Your mileage may vary....
Bill |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
Quote: |
FWIW, 16MB-1 (16777215) is the largest "01" storage-area you can define. |
Bill: I'm just curious -- where did you get this value? Enterprise COBOL supports up to 128M for both LINKAGE SECTION and WORKING-STORAGE SECTION. The CICS manual says GETMAIN with FLENGTH can get up to EDSALIMIT (or DSALIMIT, depending on which is requested) bytes of memory which for all of my regions is at least 40M and in one case is 120M (one of these days I'll have some time to figure out just what they are doing to CICS .... one of these days). |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Robert,
I believe 128M is the total amount of storage for LINKAGE and a given 01 level max is 16M-1.
But, maybe I'm wrong, cause I'm going by memory, which is prone to CRS spasms
Bill |
|
Back to top |
|
|
Robert Sample
Global Moderator
Joined: 06 Jun 2008 Posts: 8696 Location: Dubuque, Iowa, USA
|
|
|
|
The COBOL Language Reference manual says in the Limits appendix ...
Quote: |
01-49 data item size 134,217,727 bytes |
|
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
Oops, I think 16M-1 was the pre-Enterprise days.
Old habits die hard.
However, 16777211 is too big anyway (a/k/a Overkill) and the OP can reduce it as he sees fit.
111,848 records, with a record-length of 150, can be loaded into the 16777211 area.
Bill |
|
Back to top |
|
|
Terry Heinze
JCL Moderator
Joined: 14 Jul 2008 Posts: 1249 Location: Richfield, MN, USA
|
|
|
|
Quote: |
Oops, I think 16M-1 was the pre-Enterprise days. |
Yes, I believe that was the COBOL II limit. |
|
Back to top |
|
|
jctgf Currently Banned Active User
Joined: 04 Nov 2006 Posts: 109
|
|
|
|
Isn't a Temporary Storage Queue an option here? Even using the auxiliary option, handling records from it will be way faster than handling from DB2 (I think). |
|
Back to top |
|
|
|