RTP57A error message (AREV Specific)
At 06 JAN 1999 01:17:53AM Bill Budge wrote:
I am receiving the following error message:
"RTP57A String space format error" and have traced it to the following piece of RBASIC code:
CALL SCREEN.MANAGER (non expendable subroutine about 34K)
SELECT DUMMY file containing batch records
EOI=';NO.RECS='
LOOP
READNEXT ID ELSE EOI=1UNTIL EOI DO
NO.RECS=NO.RECS + 1REPEAT
If I place a debug statement immediately before REPEAT, the program loops approx 115 times and then I get the error message, followed by another message to the effect that "600 has not been cataloged. Press enter to continue". Anyone got any ideas what would cause this to happen. Arev is version 2.03. The other odd thing about this one is that if I run Arev with non-networking it works, but if it has a network driver loaded it doesn't.
At 06 JAN 1999 03:48AM Steve Smith wrote:
It would seem that something is corrupting the string space.
If you are using expanded memory try working with the AREV /XM4096
parameter set.
Are you low on memory at this point - what is the available RAM ahead of the select, using:
DECLARE FUNCTION MEMSPACE
A=MEMSPACE(999999)
PRINT A
Steve
At 07 JAN 1999 01:29AM Bill Budge wrote:
Steve,
I added the 3 statements you gave me between the CALL and the SELECT and not only did it give me the memory allocation but the error message disappeared (do not understand why though). The memory varied between 142000 and 107000 depending on how many batches I entered and processed. I was reading another entry in this database and they said that FLUSH; GARBAGECOLLECT is useful for memory corruption. Tried it but it made no difference.
At 07 JAN 1999 03:44AM Steve Smith wrote:
Something (A TSR or device driver) is screwing up memory internal to AREV, or else you PCPERFORM or SUSPEND EXIT something ill-behaved. AREV itself wont do this unless you are really low on RAM. It appears you are not too low.
It could also be one of my assembly language utils (these can do weird things sometimes )
Steve
At 12 JAN 1999 08:47PM Warren wrote:
Enter the # sign at the debugger prompt to get memory statistics after the abend.
What happens if you make the screen.manager subroutine expendable?
Are you using vspace or video.rw or extensive use of other system subroutines in screen.manager?
When 2.0x came out I found that it would start behaving very oddly when string space memory dropped below a certain point, the threshold was much higher (lower?) than v1.16. I don't recall what the threshold was/is but I coded it into one client's system to issue a warning whenever string space neared the threshold. I can look through that system to see what it was.