Hi all,

We are pseudo-supporting on old Rev/G accounting application called Reveille. The client was running a program and got the following message:

Record too long to write to disk

Line 2 'RTP12' broke because the break key was hit

I have no idea what is causing this other than a GFE. I've scanned all the known application files and they are okay. BTW, no one is actually hitting the break key. Any ideas?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions

Don,

Guessing here,

Perhaps it is a list of keys (like a quickdex) somewhere that is causing the fault.

Steve

RTP12 is SELECT

Check the LISTS file and the temp files. It has been so long I don't remember how you specify the temp files in Revelation.

It could be there is an illegal key in the file being SELECTed or something is being written to DOS outside of the 8.3 DOS naming convention.

A couple of thoughts.

1) The "…broke because the break key was hit" will appear if there is a DEBUG statement in a routine. Perhaps one was deliberately left in the code and is encountered when the length of a variable exceeded a defined length.

2) Do you have the source code? If so you can quickly isolate the section of the code experiencing the problem and trap the variable which is too long using debugs, prints, etc. (I assume this is a repeatable problem.) I work with RevG every day and would be happy to help at no charge.

Tom

Steve, Warren, and Tom,

I didn't know Rev/G supported Quickdex, so I'll try to pursue that possibility. Is there a quick way to turn it off? I saw that RTP12 refers to SELECTs so that is why I assumed a GFE.

Unfortunately I do not have source, but I do have access to the original developer. However, he is sometimes hard to reach and this had to happen on the last day of the year when the client needed to close their books. On top of that, this system is definitely not Y2K compliant. They purchased the patch but we can't apply it until the books are closed. Catch-22…

Also, I doubt this is an embedded debug statement because they have run this routine regularly for 10 years now.

Thanks for the input and Happy New Year,

dbakke@srpcs.com

SRP Computer Solutions

There's no native quickdex feature, but there was a program called INVERT.ALL, which if present on your system, creates a keylist in the * record within the data file itself. You could also

BUD VOC RECLENGTH

and enter a symbolic formula

@ANS=LEN(@RECORD)

then at TCL LIST filename RECLENGTH

you could try a CLEAR-FILE LISTS on a copy of your system to see if this helps. I've seen selects on records get "jammed" when LISTS contains large records.

Steve

It's possible that a record in the INVERT file has pushed the limits on record size, though you would probably get a 'VARIABLE EXCEEDS MAXIMUM' error or a string space error.

Inverts are normally handled through RDESIGN data entry screens although the appropriate subroutines can be called via RBASIC.

Inverts are defined in the RDES file. I forgot the structure, but contains information on which file and attributes the INVERT data is stored.

No QUICKDEX in Rev G.

I have also experienced "jamming" when the record in the LISTS file (or other programmer created cross reference) gets too large.

For the record, RevG comes with the dictionary name SIZE in the VOC file which has the formula:

@ANS=LEN(@RECORD)+LEN(@ID)+5

Steve, Warren, and Tom,

Thanks for the tips. I was able to find a record in the RDES file whose key had a reference to the file I suspected. The contents of that record had a reference to a record in another file. That record had 64K of data in it. I cleared the record and everything work just fine afterwards.

Much appreciated.

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the forum...