In a subroutine that get 5 loops deep, it breaks with the message "B703 variable exceeds maximum length." At the debugger prompt (!) typing # returns the following: (paraphrased)

2364 descriptors used

165436 bytes of string space free

PROGRAMS array consumes 216837 bytes of memory

Is this "blowing out the stack?" This program has run fine for 8 years, now I'm passing a larger group of data through it (approx doubled the records from 193 to 396). I've stripped out everything not absolutely necessary from this subroutine. I've searched the web site and implemented all of the suggestions to correct string space errors (flush;garbagecollect, removed extraneous variables, & removed my commons vars.)

Should I move out the inside loop to another subroutine?

Any suggestions would be appreciated.

The fact that your nesting is five loops deep suggests that the array is building up to be longer than 64 kB. Possible solutions include:

(a) changing the nesting sequence of the loops to reduce the number of delimiters (and thus any unoccupied space/incidence of concatenated delimiters) in the array. This will only work if the arrays have some fields unoccupied.

(b) break the master array (which gets too big) into two sections, eg. * old routine:

master.array='

a=1

for i=1 to invoice.count

for c=1 to client.count

  for p=1 to period.count

     master.array=invoices[i]:@VM:clients:@VM:periods

     a=a + 1

  next p

next c

next i

* becomes:

master.array1='

master.array2='

a=1

for i=1 to invoice.count

for c=1 to client.count

  for p=1 to period.count

     master.array1=invoices[i]:@VM:clients

     master.array2=periods

     a=a + 1 

  next p

next c

next i

Both master.array1 and master.array2 bear an implicit association of data at similar field positions.

By invoking expanded memory you may further reduce the possibility

that the master array will break.

If you post the offending routine further optimization may be possible.

Steve

[email protected]

Thanks Steve, I worked it out about an hour after I posted the error.

I like your suggested code. I just pulled out the "inner" loops that were doing the "work" and made them another subroutine.

After 8 years of tweaking extra memory for AREV, I still run into the occassional legacy code that bombs when fed a different set of data (read more records) than the program had ever processed in the 10 years since it was written.

View this thread on the forum...