Rocket U2 | UniVerse & UniData

 View Only

 Phantoms and Subroutines

Scott Johnston's profile image
Scott Johnston posted 02-19-2024 11:38

This is a two part question to solve one problem. The first part; does a called subroutine use a new block of memory and address pointer? If so, doe this newly created memory clock have to wait for a time slice before it is processed? Also if the same sub is called multiple times, will use the already created block of memory?

Part two; is it possible that calling a subroutine can break a phantom to the point of failure?

We suspect our over night phantom process is dying because a tracing file we update with a small sub is killing the phantom.

I personally do not, nor have I ever, actually known a phantom to die, because of repeated sub calls. However, we have to investigate the possibility.

Thanks,
SJJ  

Neil Morris's profile image
ROCKETEER Neil Morris posted 02-19-2024 16:58

The first call to a subroutine will load the subroutine in the current users memory space. Subsequent calls will use the already loaded subroutine. 

I can't think of any reason that simply calling a subroutine would cause a phantom to fail. There would have be some other factors involved.

Joe Goldthwaite's profile image
Joe Goldthwaite posted 02-20-2024 12:18

I agree with Neil, I doubt it's a problem with running as a phantom. It's probably a bug in the process that's independent of the phantom. Phantom processes should be set up to log their output to a file. Do  you have any logs of what it's doing? If it crashes it should have an error being logged. If it's not logging itself, maybe you could  run it in a terminal session to see what it's doing.

Independent of the phantom, calling a subroutine over and over shouldn't be a problem unless it's a nested call. A subroutine that calls itself over and over can eventually run out of stack space and crash.

Mark Sapp's profile image
ROCKETEER Mark Sapp posted 02-21-2024 10:09

Scott,  another thing to check the code for is any condition that would prompt for input.  That will kill your phantom with no warning.  Joe's comment about logging is key - I depend on logging to follow phantom activity.   I use a method of setting a variable like DEBUG.FLAG = 1 at top  and then IF DEBUG.FLAG then WRITE LOG TO FILENAME... so that you can switch off logging in the phantom program by setting the flag to zero.  Best to write out at multiple points in the program, prior to any OPEN / READ , etc. - any statements that could possibly crash.  Happy hunting :-)

Scott Johnston's profile image
Scott Johnston posted 02-21-2024 13:27

The phantom is running a reliable process that we have run multiple times without any issues. No modification to any source code. The programs were design without any inputs for the obvious reason and output is a called sub that update a log file.  We are still speculating on the failure. It is a bit of a mystery. It run  of the 8 processes in the called programs, all files are stable and we didn't find any errors in the disk file structure. Still looking.