Started happening recently with EasyWriter, AREV 2.12.
While running a report, if a field used in selection criteria has validation patterns, it breaks with this error " 'RTP27' Line 1 B12 file has not been opened.".
Running the same at TCL works fine. Is this something to do with VERBS or VOC file? How can it be fixed?
Thanks.
Sadhana
Does the validation pattern need information from another table
(i.a. validation)?
No, it's referring to the other fields in the same table.
I understand RTP27 is program loader. What's B12 referring to?
Thanks.
Sadhana
You're probably running low on string space or Program Stack slots.
The program loader is probably trying to load a symbolic (which is essentially a subroutine).
Try entering the "#" symbol at the debugger prompt and see what your string space and memory is when it crashes.
Make sure to give ARev as much conventional memory as possible and use the /X and /M4096 switches (making sure expanded memory is available). Try running your RList statement from the lowest level of TCL possible. Each time you 'shell' to another TCL level a significant amount of string space and conventional memory is 'lost'.
You're probably running low on string space or Program Stack slots.
The program loader is probably trying to load a symbolic (which is essentially a subroutine).
Try entering the "#" symbol at the debugger prompt and see what your string space and memory is when it crashes.
Make sure to give ARev as much conventional memory as possible and use the /X and /M4096 switches (making sure expanded memory is available). Try running your RList statement from the lowest level of TCL possible. Each time you 'shell' to another TCL level a significant amount of string space and conventional memory is 'lost'. Try doing an "EVAL FLUSH;GARBAGECOLLECT" prior to the RLIST statement.
Warren,
Entering '#' at debugger shows the same error. But if I enter '#' after issuing 'S' at debugger this is what it shows:
'RTP27' Line 1. B12 File has not been opened. Line 1 'RTP27' broke because a run time error was encountered.
!# Statistics after Garbage Collect:
There are 3038 descriptors used.
There are 133516 bytes of string space free.
C?
I normally don't shell out to multiple TCL. I don't have indepth knowledge of AREV,so any help is greatly appreciated.
Sadhana
Sadhana,
The B12 error message happens when you try to do a read or write sentence and the "file variable" (FILE.DATA) has not been used previously in an open sentence. Kinda like this… This paragraph of sentences will cause the error.
READ FILE.RECORD FROM FILE.DATA, FILE.ID ELSE
FILE.RECORD='
END
While this paragraph of sentences will not cause the error…
OPEN 'FILE' TO FILE.DATA ELSE
STOP
END
READ FILE.RECORD FROM FILE.DATA, FILE.ID ELSE
FILE.RECORD='
END
After all this time, I'm still learning things about Arev. I did not know about the # command from the debugger. What other debugger commands are available and not documented in the ??? command?
While debugging line by line I found that following statement, which always worked, was where the program was breaking
FC=CALCULATE('FACILITY')
I changed this to get value from COMMON.BAM
FC=@RECORD
Now it works fine. Can't figure out why when nothing was changed in the program or the dictionary it started to create problem.
Anyway, thanks to all who replied.
Sadhana
Using the @record is the prefered method of extracting data in symbolics. It's faster and consumes less resources.
The calculate and braces function "{}" essentially call a subroutine that evaluates the data using @record, @id, @dict.
You'll see similiar errors when trying to export a large number of fields with the export programs (ascii, db3, etc.)
Symholics tend to get flaky when your string spaces starts dropping below 128K particularly when they are using xlates, calculate/{}, catalyst.
I demonstrated this once in ARev 2.0x by progressively consuming string space. At some point in a symbolic doing an xlate, @record, @id and/or @dict would get corrupted after the xlate and often get set to null or some other value.
Thanks Warren. I will try to switch all CALCULATEs and {}s to @RECORD. This kind of explanations are hard to find from the manuals. Another question - couple of my programs (inherited ones) are getting too big as I do some modifications and sometimes give "running out of memory" error while compiling. Switching names of long varibles to shorter ones (e.g. SUM.OF.VOLUNTARY.LIFE to SUM.VOL), does it make any difference?
Thanks.
Sadhana
Sadhana,
Switching names of long varibles to shorter ones (e.g. SUM.OF.VOLUNTARY.LIFE to SUM.VOL), does NOT make a difference. These variable names are stored in the "*" record. Otherwise the compiler converts variable names to numberlike codes in the "$" record. Only the literal strings are stored in the "$" record. All your "comments" are ignored and removed before the compiler even thinks of actually compiling the program too. Formatting the program for ease of readability has no effect on the max compiling size.
The most simple way to reduce a very large program so it will stay below the max size is to break it up into program and subroutine. Kinda slightly difficult in the programming department only because the two seperate programs will be needing the same variable values.
A couple examples of converting some of your program to a subroutine could be…
1) If you open many files at the beginning of your program then you could do the open process in the subroutine and pass back the "file variables".
2) If you do selecting, you could do that in a subroutine.
3) Setting up report headings can be done in a subroutine.
4) Setting up entry screens can be done in a subroutine.
I am not sure any of those would apply for you. One more thing that might help. Within your program, if you have any repetative processes, you could "GOSUB" them and that way they would only be in one spot in your program rather than many.
Sounds like your DOS session memory allocation needs optimization.
What OS are you running?
How do you start Arev (shortcut on desktop or in some folder or just opening a DOS window and typing a bat file name or "AREV")?
When you first start ARev get to TCL (F5) and type "WHO" and post what it says under available memory, descriptors, expanded memory (see last page of info also).
What is the exact message you get while compiling? If it is about reaching the 34K size limit, reducing variable name length will help. If the message is about the symbol table then you have too many variables in the program. Anything else is probably due to lack of conventional memory or string space.
Do you use includes?
… its length is included in the length of code source.
Rows with the structure
$INSERT FILE_STRUCTURE
Where FILE_STRUCTURE contains rows of type
FILE$KEY EQU TO 0
FILE$SOMETHING EQU TO 1
FILE$SOMETHING_ELSE EQU TO 154
FILE_REC is the common method of accessing fields of a table.
If this is used for several tables and these tables contain a lot of fields each, you easily get out of memory errors during compilation.
I have made a "precompiler" for such purposes which inserts to the source code only used EQU's and comments the $INSERT row out.
I also check the *record after compilation not to contain a variable with $ in its name (to prevent non declared EQU).
The constants included in code source are added at the end of $record, each once. EQU's are named constants.
I have never had problem with the length of code source after the EQU trick added.
(I do structured programming (I hope) … use subroutines whenever there is a reason for it … avoid copy and paste programming!!!)
If there is no chance to code the program logic into one source, there is a way for sharing variables … common variables, or better labeled common variables.
Use it carefully, as it is not easy to synchronize distibuted code …
form debugging environment to production system.
… $INSERT strategy for common variables is recomended
LCommon variables are needed for windows pre/post processing,
other good use is in dictionary for information retrieval from other tables when several symbolics uses information from the same record of another table, the lcommon variables allows you to use just one read instead of several of them. It rapidly changes the performance.
Richard ..
I beg to differ with you. Using excessively long variable names in AREV DOES cause problems because the source code approaches the 34K limit much quicker (the 34K applies to all lines of source code, including comments). When the source code gets beyond 28K or so, then the compiler calls a pre-processor that strips out the comment lines prior to compilation. After compilation, your comment is correct. All variables are "tokenized". However, if you invoke the debugger with source trace enabled, then long variable names can cause an Out Of String Space error.
Your comments about ways to fix this are generally on target. It is also possible to use the CHAIN option. If you make subroutines that are not called repeatedly (an Open routine, for example) Expendable, then you will preserve some string space. The code may run a little slower. Another place to look carefully is how symbolics are handled in RBASIC. Any DICT call, directly or indirectly, eats up variable space and string space. This includes curly-braces calls, the CALCULATE call or imbedded XLATE's.
Just a thought ..
Don M.
Warren,
Its Windows 2000 and we access thru a shortcut on desktop (AREV 2.12 on network with NLM and 15 users). The error is like "reaching 34K maximum". There are no INCLUDEs and two INSERT$s in the program.
When I abbreviated some variable names it did manage to compile without error and that's what gave me impression that long names do affect, but wasn't sure.
This is the result of WHO at TCL
CPU Type = 80486
Math processor = 80487
Available memory = 257484
Descriptors used = 1976
Expanded Memory = Inactive
EM Used = N/A
EM Allocated = N/A
Memory Region Segment Address
16K EM Window = N/A
64K Overflow Buffer 1 = N/A
64K Overflow Buffer 2 = N/A
Thanks.
Sadhana
Okay, it would be to your benefit to get expanded memory working which would allow you have a bit more conventional memory and have more room for string space.
This topic has been discussed numerous times before and I'm too lazy :) right now to look up some of the threads, but a search on win2000/win2k/w2k and expanded memory should get you to the relevent messages on how to activate this in Win2000 and the settings you should have for the arev shortcut (pif).