Extra Segment


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.


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)



Scott Meiners


  • Whenever I encountered this memory issue, I used an indexed file as memory instead of the working storage section, but only if necessary.
  • 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.
  • 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


    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)
  • 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.
  • 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.

  • 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.
  • 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)
  • 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.
  • I have submitted a sample to support line for them to look at.
  • Compile as listing so they can look at that. The listing never lies.