RBASIC runtime problem, inability to run executables (AREV Specific)
At 29 DEC 1997 12:59:43PM Becky Mathisen wrote:
After what seems to be a successful compilation, executables will not always run and just shows a blank TCL line. AREV 2.11 is the version.
Could this have something to do with the executable being created from a different record (which ran fine)?
What is the solution?
What is the cause?
Thanks for you help!
At 29 DEC 1997 03:00PM KGilfilen wrote:
Just checking out some assumptions…
Are you certain the program doesn't run and then quit normally? Is it not branching where you expect it to?
Does the TCL line become usuable when it appears? If so then the program probably ran and finished. If not, then the program is running but who knows what it is doing?
Is the program catalogued? If it is not, and if the error message system is failing, you might not know.
Do some programs run correctly when complied and cataloged?
What do you mean, that the program in question was created from another record? Did you copy source code to another record with a different name and then compile it? Could there be some name problems, where a program is expecting the other name?
Sorry, these are pretty basic questions, but you can't assume anything in a forum. Incidently, AREV does not create executables per se. They are semi-compiled, and go through a final compile/interpretation (?) at runtime.
At 29 DEC 1997 03:41PM BMathisen wrote:
Hello, KGilfilen, thanks for responding.
Yes, I am sure that the program doesn't run and then quit normally because the output does not appear on the screen. There is no branching involved, so I don't think branching is the problem.
When the TCL line appears, it is usable.
Some other programs run correctly when compiled, and when compiled and cataloged.
The program in question was created by a recordcopy from another program, then edited to suit the new task. There could be a naming problem, but changing the name of the new record has not fixed the problem. Changing the name of the file does not fix the problem either.
I have had some success with the following procedure, but I don't know why it works:
1. Recordcopy an old program, make edits. Compile. Won't run.(Incidentally, the compile response flashes by so fast , I can't read it. How could I slow it down? Is there a pause instruction?)2. Copy the new program to a DOS directory for safe keeping..3. DeleteFile4. MakeFile CONNEW5. edit connew recordnew6. Type in simple, dummy instruction7. Compile connew recordnew8. Run connew recordnew9. Ran fine10. Edit connew recordnew11. to import DOS file containing program12. Compile connew recordnew13. Ran fine.Why does the above procedure work, at least inthe one case that I tried this morning?
Thanks again.
Becky
At 29 DEC 1997 05:29PM ed mantz wrote:
It really sounds like a programming error. If there are any errors
during the compile you will get error meesage followed by a
"press any key to continue" instruction. Sometimes depending on the
error message, number of messages and the screen updates vs scrolling
the screen, I cannot read all of the error messages but I always
get a "press any key to continue" instruction.
At this stage I think I would put a DEBUG command as the very first
line of the program and see if you go to the debugger when you
run the program.
This will tell you if you are calling the correct program.
Once you are in the debuger you can single step your
way through the program to see were you are dropping out.
Hope this helps
At 30 DEC 1997 10:19PM Eric Drews, Drews Enterprises wrote:
Just a thought as I read thru the posts here. I encountered something a while back that caused a TCL window to come up as a result of a program command, PERFORM "", EXECUTE ' ', or something line that. Check the original source code for such a possibility. Your next choice may be DEBUGs and CALL MSG in strategic locations in the program in an attempt to better determine the location of the problem.
Regards and good hunting,
Eric Drews
Drews Enterprises
908 665 2513
At 30 DEC 1997 11:47PM Michael Slack wrote:
Somthing to try:
At step 1, after you compile the newly copied record, check the file to see if it has another entry with the same name but with a dolar sign ($) in front of it. The dolar sign ($) records are the object code records. If it doesn't have one then it didn't compile in the first place. Why it wouldn't is beyond me, espeically with all the other contortions you go thru and it compiles and runs succefully.
I'm assuming that you have already looked at the edited changes you make as the possible cuprate. Could it be that you are trying to open a bad file name? If you have a statement like:
OPEN
,'FILENAME' TO FILENAME ELSE RETURN END If you hit that RETURN that would explain getting back to TCL and it ready for use and a successful compile. Or if you used something like: OPEN
,'FILENAME' TO FILENAMESELECT FILENAME
ZZZ=0
LOOP
READNEXT ID ELSE ZZZ=1UNTIL ZZZ
READ FILENAMEENDREPEAT
If the Filename wasn't opened then it would just fall thru the rest of code and end up back at TCL ready to go.
Just a thought.
Michael Slack
At 31 DEC 1997 05:18AM Charles Schmidling wrote:
Yup, sounds like a program problem.
Check your nesting. Since you copied and changed a different routine (not an uncommon occurence), you may have added modifications that unwittingly changed your nesting.
If an extra "END" is found, the compiler stops right there and doesn't see the rest. No error message is produced and you can run a severely shortened routine. Check the "number of lines compiled" statement versus what you think is there.
If an "END" is forgotten, your logic structure fails and you could even lose the whole rest of the program in a DO block. The compiler adds "END"s to the end of a program so you won't get a logical end of program error.
Check command usage. I've had a simple typo yield a couple of useless error msgs and kill the compile or even freeze my system.
Then again, you could always start from scratch.
Much luck,
Charles Schmidling
DATASCAN Systems, Inc.