can you call a subprogram twice and have two separate instances?

I want to create utility X.  I want to call utility X in program A and program B.  Program A runs, calls X, does work, then calls B.  B will also call program X.  This new X needs to start fresh and preserve state (file status, working storage) separate from the first instance. while B uses it.  Eventually B will shut down X #2, and return to A, which needs X #1 to remember it's file state and working storage.

 

The manual says that you only have one instance of X in memory, and therefore only state, unless it is called in two different threads.  I don't want to run A and B as separate threads.  I could run X in it's own separate thread, but then I cannot call that instance again, because it's now in a separate thread - I would have to send messages back & forth instead of using the linkage area to pass back & forth. 

Anyone know how to call a specific instance of X?  (I was hoping the call would allow calling with thread handle already set, but that's not what the manual says)

  • Verified Answer

    You can't do what you want. But there is a simple workaround.

    Start program B in a thread, and from program A, immediately wait for a message from B (effectively not using threads). When B is finished, send that message to A, allowing A to continue. In that way, X is running two separate instances.

    Note that I have not tried this, but it should work.

  • Hi

    Sometimes we need the same and we use this workaround:

    - Write the X utility

    - Compile the X utility and have the X object (for now I call XOBJ)

    - Copy the XOBJ in YOBJ

    - Program A calls XOBJ

    - Program B call YOBJ

    Finally, if you're working in Linux environment, you can also use symbolic link instead of the copy of the object:

    - Install the XOBJ file

    - Link the XOBJ to the YOBJ

    Since now, every time you update the XOBJ, the system updates also the YOBJ, so you don't need to do it by yourself

  • Thank you both.  I simplified the plan for my example, it could go beyond two instances, but both ideas could be used with a bit of work.

    I plan to use the thread idea.  The manual says that variables passed by reference are shared between caller and called.  So I just have to, as suggested, call the program which should then go into a loop waiting for an incoming message.  The caller then sends a message, eg the string "CALL", to the sub-program then immediately does a receive to wait for the subprogram to finish/exit.  The subprogram gets the "call" message,  does it's thing and sends back "DONE", and loops back to it's receive command.  The caller can then resume and any changes the subprogram made to the using variables will be available.  Cancel gets replaced by close thread.

    The trick PiGi mentioned could become a managed thing - have a copy library that calls a utility to get the next "unused" version of the program name for the program being called.  If that file doesn't exist yet, then the manager would link (or copy) the original to that name (XXXX, then XXXX1, then XXXX2 etc).  Main program can call that unique name.  Just remember to call a routine from the library to "cancel" the linked program so it can be marked as not-used.  This has the advantage that each called program is unique and you can use the "USING" to pass parameters.  The manager utility would leave the copies sitting around so they "cache".  I would probbably put them into a work folder, so an update can purge the old copies of the updated programs, and the manager can just rebuild the cache.