Sign up on the Revelation Software website to have access to the most current content, and to be able to ask questions and get answers from the Revelation community

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!

[email protected]


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.  DeleteFile 
  4.  MakeFile CONNEW
 5.   edit connew recordnew
 6.   Type in simple, dummy instruction
 7.    Compile  connew recordnew
 8.    Run  connew recordnew
 9.     Ran fine
10.    Edit connew recordnew
11.     to import DOS file containing program
12.    Compile connew recordnew
13.   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 FILENAME

SELECT FILENAME

ZZZ=0

LOOP

READNEXT ID ELSE ZZZ=1

UNTIL ZZZ

READ FILENAME
END

REPEAT

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.

[email protected]

View this thread on the forum...

  • third_party_content/community/commentary/forums_nonworks/6e2b64eb596c87fc8525657c0062da0d.txt
  • Last modified: 2023/12/28 07:40
  • by 127.0.0.1