ibmi-brunch-learn

Announcement

Collapse
No announcement yet.

Large DS and Automatic storage overflow

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Large DS and Automatic storage overflow

    So I have some big data structures. the program compiles fine but when i get to use the DS it blows up and gives me the Automatic Storage Overflow.

    I seen that on a service program you can specify STGMDL(*TERASPACE) but I do not see an option on CRTSQLRPGI. Anyone know of a work around. Sadly I can not trim the size of the DS. I have changed all Zoned to packed hoping that would help but no go. I have some arrays in there as well and I really really don't want to trim the dim down.

    What I am trying to do is build a DS for a set of tables. This DS is then passed to and from a service program to get the data or update the data.

    Hunting down the future ms. Ex DeadManWalks. *certain restrictions apply

  • #2
    CRTSQLRPGI doesn't support several options (ACTGRP amongst them).
    You can create the program as a module, then use CRTPGM which has the STGMDL parameter.

    Comment


    • #3
      There's lots of workarounds... but in order to recommend a solution, I would need to be familiar with your program and why it is overflowing automatic storage.

      To be honest, I chuckled when you said you tried converting your numbers from zoned to packed. You can't seriously have THAT many numbers in your automatic storage, can you?! Even a fairly large number, like 15S 2 converted to 15P 2 only saves 7 bytes. Automatic storage in the standard STGMDL(*SNGLVL) is just under 16 mb. That's a LOT of numbers.

      Most likely you have something like arrays of large strings, or arrays of data structures that contain nested arrays, or something like that if you are running out of automatic storage. Also remmeber the automatic storage limit is not per program or per proedure -- it's PER JOB. So the total of all automatic storage on all active procedures/programs in the job is what counts. My experience with these things is that there's usually one procedure that's really hogging storage with huge strings, arrays, structures, etc. Often times it's not where the limit is hit, but it uses a ton of memory and then when the next procedure is called, the next procedure just happens to "tip the scale" or "place the straw that broke the camel's back" or whatever...

      Anyway, that's where I would investigate. Look to see if there's a procedure with a huge amount of automatic storage and see if you can clean it up. If you can't reduce the storage it uses, you could at least change it to use heap storage and solve the problem that way.

      If all else fails, you can switch to *TERASPACE. But, I consider that a "lazy option". It's like putting an expansion on your house because you don't want to do spring cleaning. Of course, there are times when you really have nothing else to get rid of, and you really do need the expansion,,, but most of the time, it's just that something needs to be cleaned up better.

      If you really do need to use STGMDL(*TERASPACE), you can specify it on the CRTSQLRPGI command by using the COMPILEOPT() parameter. This parameter merely contains keywords that get passed onward from the precompiler to the actual RPG compiler. So you can do COMPILEOPT('STGMDL(*TERASPACE)') and it'll tell the actual compiler to make it teraspace.

      Comment


      • #4
        Thanks, i was able to trim my dims down to a comfortable level.
        Hunting down the future ms. Ex DeadManWalks. *certain restrictions apply

        Comment

        Working...
        X