IBM Mainframe Forum Index
 
Log In
 
IBM Mainframe Forum Index Mainframe: Search IBM Mainframe Forum: FAQ Register
 

Memory issue with index by occur clause.


IBM Mainframe Forums -> COBOL Programming
Post new topic   Reply to topic
View previous topic :: View next topic  
Author Message
udish_85

New User


Joined: 29 Nov 2010
Posts: 2
Location: Hyderabad

PostPosted: Mon Nov 29, 2010 6:37 pm
Reply with quote

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
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Mon Nov 29, 2010 7:05 pm
Reply with quote

It sounds like you are using an obsolete version of the Cobol compiler. Check with a colleague or your systems folks.
Back to top
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Mon Nov 29, 2010 7:05 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Mon Nov 29, 2010 9:53 pm
Reply with quote

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
View user's profile Send private message
udish_85

New User


Joined: 29 Nov 2010
Posts: 2
Location: Hyderabad

PostPosted: Tue Nov 30, 2010 6:38 pm
Reply with quote

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
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Tue Nov 30, 2010 6:53 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Nov 30, 2010 9:16 pm
Reply with quote

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
View user's profile Send private message
Bill O'Boyle

CICS Moderator


Joined: 14 Jan 2008
Posts: 2501
Location: Atlanta, Georgia, USA

PostPosted: Tue Nov 30, 2010 10:00 pm
Reply with quote

/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
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Wed Dec 01, 2010 6:56 pm
Reply with 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.

There are many ways this method can go wrong, and I do NOT recommend it.
Back to top
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Wed Dec 01, 2010 7:34 pm
Reply with quote

Walks like a recommendation, talks like a recommendation, smells like a recommendation.
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Wed Dec 01, 2010 7:41 pm
Reply with quote

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
View user's profile Send private message
Phrzby Phil

Senior Member


Joined: 31 Oct 2006
Posts: 1042
Location: Richmond, Virginia

PostPosted: Wed Dec 01, 2010 7:43 pm
Reply with quote

But sometimes in a pinch (read emergency) a well-controlled and monitored workaround is required.
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada

PostPosted: Wed Dec 01, 2010 8:05 pm
Reply with quote

Phrzby Phil wrote:
Walks like a recommendation, talks like a recommendation, smells like a recommendation.
Naw, I was just being evil. icon_evil.gif
Back to top
View user's profile Send private message
enrico-sorichetti

Superior Member


Joined: 14 Mar 2007
Posts: 10872
Location: italy

PostPosted: Wed Dec 01, 2010 8:08 pm
Reply with quote

Quote:
Naw, I was just being evil.


all depends how long is Your experience, I have seen things worse than that
!
sometimes... evil == realistic icon_biggrin.gif
Back to top
View user's profile Send private message
shobhit.baijal

New User


Joined: 27 Mar 2009
Posts: 6
Location: Chennai

PostPosted: Tue Dec 21, 2010 1:29 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Tue Dec 21, 2010 9:35 pm
Reply with quote

Hello,

This would depend on the erroneous code that flushed the "other" . . .
Back to top
View user's profile Send private message
shobhit.baijal

New User


Joined: 27 Mar 2009
Posts: 6
Location: Chennai

PostPosted: Wed Dec 22, 2010 1:20 pm
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Wed Dec 22, 2010 9:09 pm
Reply with quote

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
View user's profile Send private message
shobhit.baijal

New User


Joined: 27 Mar 2009
Posts: 6
Location: Chennai

PostPosted: Thu Dec 23, 2010 11:30 am
Reply with quote

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
View user's profile Send private message
dick scherrer

Moderator Emeritus


Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix

PostPosted: Thu Dec 23, 2010 8:25 pm
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic View Bookmarks
All times are GMT + 6 Hours
Forum Index -> COBOL Programming

 


Similar Topics
Topic Forum Replies
No new posts SFTP Issue - destination file record ... All Other Mainframe Topics 2
No new posts Cobol file using index COBOL Programming 2
No new posts Issue after ISPF copy to Linklist Lib... TSO/ISPF 1
No new posts To search DB2 table based on Conditio... DB2 1
No new posts Facing ABM3 issue! CICS 3
Search our Forums:

Back to Top