View previous topic :: View next topic
|
Author |
Message |
udish_85
New User
Joined: 29 Nov 2010 Posts: 2 Location: Hyderabad
|
|
|
|
Hi!
I need to increase the count of occur clause in my program but getting the compilation error when trying the same. Below is the error message.
'FIXED LENGTH GROUP ITEM IN WORKING STORAGE OR LINKAGE SECTION IS GT 131,071 BYTE TRUNCATED TO 131,071'.
The current count of occur cluase is 685 and fixed length of single occurance of array is '350'.
Please advise how to trouble shoot this issue. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
It sounds like you are using an obsolete version of the Cobol compiler. Check with a colleague or your systems folks. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
The maximum "01" level length for OS/VS COBOL (which is what I believe you have) is 128K. This is a compiler restriction. You need to inform management that they need to upgrade to a more "modern" compiler. OS/VS COBOL was withdrawn from service in June 1994.
Keep in mind that this upgrade will require source-code changes, especially to COBOL/CICS programs.
Bill |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello and welcome to the forum,
If a currently supported version of the compiler is not available on your system, you might consider changing the length of an occurrance to less than 350 and use a pair (or more) of arrays. |
|
Back to top |
|
|
udish_85
New User
Joined: 29 Nov 2010 Posts: 2 Location: Hyderabad
|
|
|
|
Thanks a lot for all your valuable inputs. I feel that splitting the array into 350 will make design more complex. Moreover i would need to change the code in two different modules each having code of 55k lines. These modules are main and very cirical from application perpective. I will discuss with management for compiler upgradation but need to work on cost associated and it's impact. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
IMO your management would be very foolish not to allow a compiler upgrade. There will be some conversion costs, but they will be more than offset by lower maintenance costs down the road. The use of END-IF, for example, will make it much easier to insert new logic into the program. |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
The system can be "phased-over" to a current version of the compiler - there is no requirement to do everything at one time. |
|
Back to top |
|
|
Bill O'Boyle
CICS Moderator
Joined: 14 Jan 2008 Posts: 2501 Location: Atlanta, Georgia, USA
|
|
|
|
/Flame Proof Suit On
If you centralize this table into an Assembler CSECT and calculate the number of entries (during Assembly) and place this calculation in the first 4-Bytes as a fullword-binary, a small Assembler program, which issues an MVS LOAD Macro and returns the LP address, would work. You would need a single 350-Byte DSECT in LINKAGE and you would bump through it, starting at the LP Address plus 4, increasing the address (BLL Cell) by 350 each time, until you've exceeded the number of entries. Of course, the overhead up front would have to be dealt with in defining this CSECT and filling it up. With that, after migrating to (at a minimum COBOL/370), you can use a PROCEDURE POINTER (NOT to be used in CICS) to simulate what the MVS LOAD macro does.
/Flame Proof Suit Off
Bill |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
One of the traditional workarounds to the table size limitation is to define the table to the maximum allowable by the compiler, then code a large FILLER area right after it. Then you can deliberately let your subscript overflow into it.
There are many ways this method can go wrong, and I do NOT recommend it. |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1042 Location: Richmond, Virginia
|
|
|
|
Walks like a recommendation, talks like a recommendation, smells like a recommendation. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
One of the traditional workarounds to the table size limitation is to define the table to the maximum allowable by the compiler, then code a large FILLER area right after it. Then you can deliberately let your subscript overflow into it. |
... as a workaround it really stinks !
unless somebody introduced in IT the concept of...
planned overflow,
along with
planned unmanaged error
planned mishandling of data
planned un***** what ever You want
planned mis**** what something more You want |
|
Back to top |
|
|
Phrzby Phil
Senior Member
Joined: 31 Oct 2006 Posts: 1042 Location: Richmond, Virginia
|
|
|
|
But sometimes in a pinch (read emergency) a well-controlled and monitored workaround is required. |
|
Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010 Posts: 765 Location: Whitby, ON, Canada
|
|
|
|
Phrzby Phil wrote: |
Walks like a recommendation, talks like a recommendation, smells like a recommendation. |
Naw, I was just being evil. |
|
Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007 Posts: 10872 Location: italy
|
|
|
|
Quote: |
Naw, I was just being evil. |
all depends how long is Your experience, I have seen things worse than that
!
sometimes... evil == realistic |
|
Back to top |
|
|
shobhit.baijal
New User
Joined: 27 Mar 2009 Posts: 6 Location: Chennai
|
|
|
|
Hi All,
I have a similar problem, I had a 01 Level variable with lots of tables defined under it, all with different subscripts and with depending on clause.
It happened in particularly with 2 tables, the one which was loaded the last retained its values, while the other got flushed. No compilation/run time errors were there.
I have it rectified by declaring these 2 tables under separate level 01 each.
But since I am using Enterprise Coblol and don't think that i would have crossed 16Mb limit, I was just looking for an explaination on why was it happening.
Regards,
Shobhit |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
This would depend on the erroneous code that flushed the "other" . . . |
|
Back to top |
|
|
shobhit.baijal
New User
Joined: 27 Mar 2009 Posts: 6 Location: Chennai
|
|
|
|
Hi Dick,
This is happening when 2 consecutive loads take place.
We have 2 cursors each for a table.
We open, fetch, load the first table and close the cursor.
And then repeat this for the second one.
No other process happens in between, all the variables and subscripts are different.
More importantly, I just gave a 01 Level Variable before each table (i.e. they are under an independent 01) and they worked fine, no code changes and no variable names changed. Can there be any addressing issue?
Regards,
Shobhit |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Quote: |
Can there be any addressing issue? |
Most likely not by the system. . . I suspect that if you run only one or the other (and nothing else) it will work.
The code is possibly "doing more than it should" and destroying the content of the problem array.
Suggest you display one entry immediately after the load of the array and then display the same entry later in the code after more "work" has been done. If the initial load was correct (and from what you have posted, it sounds like it is) the first display will have the proper values. |
|
Back to top |
|
|
shobhit.baijal
New User
Joined: 27 Mar 2009 Posts: 6 Location: Chennai
|
|
|
|
Done with the displays. The entries from first array start vanishing as soon as the second array starts loading.
And, the problem gets resolved when we remove the depending on clause and make the arrays to be of static nature.
Regards,
Shobhit |
|
Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006 Posts: 19244 Location: Inside the Matrix
|
|
|
|
Hello,
Then you need to determine why/how the code is destroying these entries.
I believe it is important to understand why there is a problem. "Getting around" the problem may only lead to later problems (in Production at 3a.m.) when it may be a crosis . . .
The problem may be in the definitions (there may be some unintended overlap) or in some incorrect index/subscript usage. |
|
Back to top |
|
|
|