Skip to main content
Question

Phantoms and Subroutines

  • February 19, 2024
  • 4 replies
  • 0 views
S

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  

    4 replies

    Neil Morris
    • Neil MorrisRocketeer
    • Rocketeer
    • 207 replies
    • February 19, 2024

    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  

    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
    • Joe Goldthwaite
    • Participating Frequently
    • 124 replies
    • February 20, 2024

    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  

    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
    • Mark SappRocketeer
    • Rocketeer
    • 20 replies
    • February 21, 2024

    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  

    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 :-)

    S
    • Scott Johnston001
    • Author
    • Participating Frequently
    • 6 replies
    • February 21, 2024

    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  

    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.


    Terms & ConditionsAccessibility statement