Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
scottmeiners
Visitor.
1790 views

Extra Segment

Hello,

Our company would REALLY like the 64k limit of the extra segment enlarged.  We have recently hit it with one of our billing program and are very close to exceeding in in a couple of others.  I was wondering if any other users have hit this limit and/or would also like to see it increased?

We have also found it very difficult to understand what actually makes up this extra segment because it is not very clear according to the documentation as to what it is.  We have been using the Acu stuff for 20+ years and our product and our programs have gotten rather large and very complex.  We have tried to clean things up, but in doing that we have had some strange results.  In reviewing some copy books that we use we have found some fields that are no longer being used so we thought that removing some of these fields might help.  We removed some fields and the extra segment did not change, however, once we got to one field that we removed the extra segment from our program went form 63366 to exceeding the 64k limit which does not make any sense.  The field was a pic 999 usage comp-1 value 0 field.  So now removing fields has us a little concerned.  Is there a way to see what makes up the extra segment?

Here are the compile statistics before we remove the 1 pic 999 usage comp-1 field.


STATISTICS

Total Lines: 140080
# of Files: 0
# of Data Items: 20998
# of Paragraphs: 3237

Elapsed Time: 2.1 seconds
Lines/Minute: 3927476


Code Size: 445546 (06CC6A)
Data Size: 4612636 (46621C)
Shared Data: 9626 (00259A)
Extra Segment: 62252 (00F32C)
Thread Segment: 13212 (00339C)
Address Table: 46040 (00B3D8)
Program Size: 5189312 (4F2EC0)

 

Thanks,

Scott Meiners

DRFCO

0 Likes
19 Replies
GeorgeK Absent Member.
Absent Member.

RE: Extra Segment

Whenever I encountered this memory issue, I used an indexed file as memory instead of the working storage section, but only if necessary.
0 Likes
mhanson Absent Member.
Absent Member.

RE: Extra Segment

What version of the Acu products are you using? ECN-4419 in version 10.1.0 may help your situation. The description from the ECN is:
<<
File descriptors occupy a variable amount of space in memory depending on many factors, including the number of alternate keys declared for the file. The total amount of space available for file descriptors in any one object file is 64KB. Starting in version 10.1, this limitation is removed; file descriptors now occupy "regular" memory along with other data descriptors.

In prior versions, a program that overflowed this space would not compile and issue the error "Extra segment too large".
>>

I don't see a listing option that spells out exactly which parts of the program go into the extra segment. There may not be a clear way to indicate which parts of a program use space in the extra segment, as this is all tied closely to the internal implementation which is not available to the end user.
0 Likes
scottmeiners
Visitor.

RE: Extra Segment

We are already on 10.1.0, so this ecn does not help. I actually included the incorrect compile statistics. Here are the stats for the one that was crashing:

Start U02010PG.CBL
Data Division
Procedure Division
Writing Code Addresses
Including Resources
U02010PG.CBL Wed Jun 06 16:35:22 2018 ACUCOBOL-GT v10.1.0 + 4460 + 4463 + 4464 + 4465 + 4469 + 4474 + 4504 + 4545 + 4548 Page: 0001
ccbl32 -o ..\U02010PG.COB -v -Li -Ta 32768 -Td 8000 -Cr -Cc U02010PG.CBL
CBLFLAGS: -v -Li


STATISTICS

Total Lines: 138425
# of Files: 0
# of Data Items: 18359
# of Paragraphs: 3255

Elapsed Time: 2.1 seconds
Lines/Minute: 3809862


Code Size: 553620 (087294)
Data Size: 10703560 (A352C8)
Shared Data: 9615 (00258F)
Extra Segment: 63366 (00F786)
Thread Segment: 13404 (00345C)
Address Table: 49684 (00C214)
Program Size: 11393249 (ADD8E1)
0 Likes
DrakeCoker Absent Member.
Absent Member.

RE: Extra Segment

The "extra segment" is a holdover from 16-bit days. It used to hold all of the data descriptors. Very nearly all of those now live in other places, but there are odds-and-ends that still live in the extra segment. Descriptors of files (not the record layouts, but things like key structure), Screen Section descriptors (usually the biggest thing there) and miscellaneous other things. "Normal" programs, even very large ones, struggle to fill it up, but sometimes a program will make heavy use of something that still lives there. On the COBOL side, it is very hard to figure out what those might be, but Micro Focus tech support can figure it out from the compiler side with access to the source code. In the past, this has lead to compiler improvements where the offending item is moved out of the extra segment, avoiding the issue entirely.

Actually increasing the extra segment is difficult due to reasons stretching back in to prehistoric times. It is simply easier to eventually migrate everything out of there.
0 Likes
scottmeiners
Visitor.

RE: Extra Segment

The thing that is odd is the removing of one variable from the program causes the extra segment to increase from 63366 to over 64k? We were assuming that removing variables would decrease the size and not increase it. This field is in a copy book that is also in another program and before we removed it, the size was 62252 and is now 64314. So removing a pic 999 usage comp-1 field increased the extra segment by 2062 which does not make sense.

0 Likes
DrakeCoker Absent Member.
Absent Member.

RE: Extra Segment

I find that confusing myself in that I can't immediately think of a scenario where that would occur. It would be fun to debug (well interesting at least). The extra segment is tricky to understand from the COBOL side because it largely does not depend on the size or type of the COBOL variables, but in how they get used. The compiler has multiple ways of creating code and associated descriptors for many constructs, so the factors that cause it to choose the extra segment are very not obvious from the outside. Once it creates something, it likes to reuse it too, adding another layer of opaqueness.

Normally, unused data items are simply not described anywhere in the object, so I'm unclear what would cause the behavior you see.
0 Likes
RobertRedekop Trusted Contributor.
Trusted Contributor.

RE: Extra Segment

Speculation (because I've done this): If your file has 2 record layouts but they are the same length, and you remove a field from one of the record layouts, now you have a varying record size. That is more complicated, and perhaps could affect the extra segment. You probably aren't doing this, but it's an example of a way to do something simple that causes complications... (I'm going to assume you put the field back to confirm that this is the change that modified the extra segment size)
0 Likes
scottmeiners
Visitor.

RE: Extra Segment

We will work on getting this program in a way that we can send it to support line. Unfortunately this is one of the most complex programs that we have. It has lots of screens, over a 100 and lots of copy books so it will take some work. We also had issues where we had variable in a copy book on line 900 and we got the error. We then moved the variable to the end of the copy book, line 1500 and the program compiled. It will be interesting to see what is causing this, kind of has us concerned as we don't really want to a rewrite.
0 Likes
scottmeiners
Visitor.

RE: Extra Segment

I have submitted a sample to support line for them to look at.
0 Likes
GeorgeK Absent Member.
Absent Member.

RE: Extra Segment

Compile as listing so they can look at that. The listing never lies.
0 Likes
DrakeCoker Absent Member.
Absent Member.

RE: Extra Segment

I've been looking at the program. I still don't know why removing that data item has the effect that we see. It's a fairly dramatic change (something like 300 data items decide to jump into the extra segment for descriptors). It feels like it could be a bug, though I don't see anything specific that isn't working right.

More usefully, I can tell you that what is eating up the vast majority of the space are screen descriptions (specifically, unique data item references in screens, mostly property settings). I'm trying to see if there is some way to make that less of an issue. In the meantime, if you just flat-out run into a wall, you can try moving a screen or two into a called subroutine to free space.
0 Likes
dalekreitzer
Visitor.

RE: Extra Segment

No idea if this will help or not, but try moving your code around ... we've had similar issues a long time ago that we solved simply by moving paragraphs around in the code.

Dale

0 Likes
scottmeiners
Visitor.

RE: Extra Segment

Drake,
Thanks for the information. For right now, we have the programs at a place where it will hopefully not hit the wall but they are closer than we like. We really don't want to do a rewrite of stuff unless we really have too. Hopefully you are able to make it less of an issue.
Scott
0 Likes
GeorgeK Absent Member.
Absent Member.

RE: Extra Segment

Yes, and it can be extremely sensitive to the position of the variables in working storage. If they are using Acubench, it can be even more sensitive than Acucobol-GT (Microfocus Extend). For example, just deleting a variable in working storage in Acubench doesn't necessarily delete it as far as the ide is concerned. The ide may point to the next variable as if it was the deleted variable. That is due to the pointers attached to the deleted variable I think.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.