this is from the result viewer ..

program X calculates the sum of the lenghts of @id and records in SYSVOLUMES + SYSTABLES .. the

tables in RTP50 ….

I get variable exceeds maximum length when the result from X is around 103000

a CLOSE function would be a good thing, 'cause it could remove line 5 in the SYSTABLES posts …..,

and thereby reduce the space consumed by SYSTABLES ..

as it is now, there's absolutely no way to stop the RTP50 from groving, except from now and then

execute DETACH_VOLUME …..I guess an ATTACH + DETACH will 'close' files

Is there a 'hidden' way to clean out things in SYSTABLES ????

/Bengt

—- must be read from the buttom .. upwards ….. —-

RUN X – get new size, size of SYSTABLES has increased, as expected …

94594

Request successfully executed. 1 row(s) processed.

RUN XOPEN 'DICT.KR_FAKTURA'

DICT.KR_FAKTURA

Request successfully executed. 1 row(s) processed.

RUN X – get new size

94555

Request successfully executed. 1 row(s) processed.

RUN XOPEN 'DICT.LR_FAKTURA' — open own table

DICT.LR_FAKTURA

Request successfully executed. 1 row(s) processed.

RUN X

94516

Request successfully executed. 1 row(s) processed.

run xopen 'SYSREPOSWINS'

SYSREPOSWINS

Request successfully executed. 1 row(s) processed.

RUN X – cleanup successful

94516

Request successfully executed. 1 row(s) processed.

RUN DETACH_VOLUME 'E:\TMP\X' –

E:\TMP\X 1

Request successfully executed. 1 row(s) processed.

RUN X – get space

95775

Request successfully executed. 1 row(s) processed.

run attach_table 'E:\TMP\X' – attach a small volume with around 10 tables

E:\TMP\X ORION 1

Request successfully executed. 1 row(s) processed.

run x – estimate space consumed by RTP50

94516

Request successfully executed. 1 row(s) processed.

Bengt,

program X calculates the sum of the lenghts of @id and records in SYSVOLUMES + SYSTABLES .. the tables in RTP50 …. I get variable exceeds maximum length when the result from X is around 103000

The data in SYSTABLES and SYSVOLUMES are stored in dimensioned global variables. The layout is such that element (0) is an @fm-delimited list of keys, (1) is an @fm-delimited list of the data seen in field 1 of SYSTABLES/SYSVOLUMES, and so forth. Any of the elements can be up to 64k (65531 bytes). Since SYSVOLUMES takes little space, I can assume that SYSTABLES is the offender. The largest field (typically) in SYSTABLES is field 5 (element (5) of the dimensioned array) which contains the return value from the OPEN.FILE call to the MFS/BFS chain.

1) If you have MFS's, don't put huge amounts of data into the Record value returned from OPEN.FILE

2) Index file handles use more space than regular file handles (mainly because they don't obey rule #1 above)

3) Unless a file has been opened (i.e. the BASIC+ open statement) there will be no value in field 5

4) Detaching and re-attaching a table will clear its handle (field 5)

Cameron Purdy

[email protected]

yup .. the SYSTABLES records was the prob, and the prob originates

from a BFS ..

I have a q though .. in AREV there is a function called CLOSE_TABLE,

just because of possible problems if running BFS ..

However, I have found a workaround, I store my filhandles locally,

and let OPEN.FILE return a pointer to the local area instead, wasn't

too much work involved …

Theoretically however, your solution with never closing files don't

work, sooner or later the RTP50 volume will 'exceed maximum length',

the workaround with detaching/attaching volumes is no good, as it

might be slow ..and it might be hard to know which files you have

attached from which volume …

anyways .. no more panic in this …

/Bengt

View this thread on the forum...