Skip to main content

Extra Segment

  • June 6, 2018
  • 19 replies
  • 0 views
Scott Meiners

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

    19 replies

    D

    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

    Whenever I encountered this memory issue, I used an indexed file as memory instead of the working storage section, but only if necessary.
    D

    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

    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.
    Scott Meiners
    • Scott Meiners
    • Author
    • Participating Frequently
    • June 7, 2018

    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

    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)
    D

    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

    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.
    Scott Meiners
    • Scott Meiners
    • Author
    • Participating Frequently
    • June 7, 2018

    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

    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.

    D

    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

    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.
    Robert Redekop
    • Robert Redekop
    • Participating Frequently
    • June 7, 2018

    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

    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)
    Scott Meiners
    • Scott Meiners
    • Author
    • Participating Frequently
    • June 7, 2018

    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

    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.
    Scott Meiners
    • Scott Meiners
    • Author
    • Participating Frequently
    • June 7, 2018

    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

    I have submitted a sample to support line for them to look at.
    D

    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

    Compile as listing so they can look at that. The listing never lies.
    D

    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

    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.
    A
    • Anonymous
    • June 13, 2018

    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

    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.
    Scott Meiners
    • Scott Meiners
    • Author
    • Participating Frequently
    • June 13, 2018

    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

    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
    D

    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

    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.
    D

    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

    Sorry for my extended silence. I spent some time trying to figure out what is going on, but it remains a mystery! The problem is there are over a hundred places where something can get put into the extra segment and tens of thousands of hits on these in the sample program, so finding where things change is a large effort. So, I took a different approach...

    Starting in version 10.3, the "extra" segment will be doubled in size, up to 128KB. This is something that could be put into the existing runtime without a large-scale rework (exceeding 128KB *is* a large rework). This should allow you to put nearly twice as many screen items into the program as currently exist, so hopefully will see you through the foreseeable future. This change is ECN 4567.
    Scott Meiners
    • Scott Meiners
    • Author
    • Participating Frequently
    • July 24, 2018

    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

    Thanks for the update!!
    D

    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

    When will Extend 10.3 be released?
    Is it possible to get a patch for an earlier version?
    And if so, does the patch affect only the compiler or does the runtime have to be exchanged?
    Stephen Hjerpe
    • Stephen Hjerpe
    • Participating Frequently
    • July 24, 2018

    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

    10.3 is currently scheduled for late 2019. This change cannot be patched into an existing version, the change involves header information which 10.3 will read correctly but earlier runtimes will not be able to deal with that change.
    D

    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

    Mystery of the data item solved... that data item is two bytes in size. In RM/COBOL compatibility mode (-Cr), the "sync limit" is set to "2".  By removing two bytes, some larger native data items (such as EVENT-DATA-2) ended up misaligned, which causes the compiler to use the more general, but less efficient, extra segment descriptors. 

    You can get the program to compile by removing the restricted "sync limit" property of -Cr by compiling with "-Dl8" also.  This overrides the RM/COBOL compatibility with our default of full synchronization of synchronized data.  Removing -Cr also works, but of course, you get other issues then. 

    Unless you put binary, synchronized data into records, this is very unlikely to hurt anything (I've never seen anyone put SYNC on record data before, though it, of course, can happen).

    Recent badge winners

    Explore all badges
    Terms & ConditionsAccessibility statement