PJP Documentation > Reference Manual Menu
Several PJP users have had trouble using stacked inputs entered on the Process Detail Screen. These problems have often been due to the specified process modifying the input buffer in unexpected ways. Our activities in troubleshooting occurrences of this problem have led us to the conclusion that stacked inputs, if used at all, should be used very cautiously.
When stacked inputs have been specified for a process, the main phantom program (PHANTOM.DRIVER) interprets them as necessary and loads them into the system’s input buffer using DATA statements in the BASIC programming language. As the process is executing, anytime that user input is required, the next piece of data is removed from the stack and used as if it was entered from the keyboard.
When a phantom process needs input and there are not any stacked inputs left, the end result is different depending upon the software platform.
- For jBase, the process being executed terminates and control is returned back the main phantom program. It looks like the process completed, but it didn’t. It aborted due to lack of input.
- For UniVerse, an unresolved need for input causes the entire phantom to terminate. This will lead to a “hung phantom” status.
If a paragraph to be executed by the phantom contains DATA statements, these will conflict with stacked inputs. You should not try to mix stacked inputs with paragraph DATA statements.
Many of the processes executed from CU’s menus are proc-based. “Proc” is a scripting language. Unfortunately, most of the Procs written by CU contain the command “RI” which resets the input buffer. Once the RI command is executed, all of the specified stacked inputs are lost. For this reason, it is not a good idea to try to run CU’s procs without some degree of customization of those procs.
The BASIC programming language has the ability for a program to launch another program or a system command using the EXECUTE verb. Many programs in the CU environment, both CU programs and custom programs, make use of this powerful feature. Unfortunately, some of the system commands that are commonly used have an unexpected effect on the input buffer. The commands that we’ve found which give us trouble are SELECT and GET-LIST. Presumably, any other commands which can result in a list becoming active (such as SSELECT, QSELECT, etc.) will also affect the input buffer. The effect is not the same for jBase and UniVerse, so we’ll discuss them separately.
When a jBase program, running as a process under a phantom, executes a SELECT or GET-LIST command, there can be two scenarios. In the event that no list is generated (i.e. the SELECT is unsuccessful or the GET-LIST list name doesn’t exist), the input buffer is cleared. If a list is generated, the next data element in the input buffer is looked at as if it were a program name to be executed, and the rest of the input buffer is cleared. In most cases, the stacked data will not contain a valid program name to execute, so an error message is generated. In either case, the input buffer is cleared. When the next input statement is encountered the program will terminate and return control to the main phantom program.
When a UniVerse program, running as a process under a phantom, executes a SELECT or GET-LIST command, there can be two scenarios. In the event that no list is generated (i.e. the SELECT is unsuccessful or the GET-LIST list name doesn’t exist), the input buffer is left untouched. If a list is generated, the next data element in the input buffer is looked at as if it were a program name to be executed, and is popped off of the stacked inputs. In most cases, the stacked data will not contain a valid program name to execute, so an error message is generated.
In UniVerse, predicting which piece of stacked data will be fed to the next input after executing a SELECT statement is troublesome. It depends upon whether a list was generated or not. If, because of the fact that an extra piece of data was used, the final input requirement in a program is left unsatisfied, the entire phantom will be aborted and eventually recognized as “hung”.
Don’t use stacked inputs for programs which execute system commands which can result in a list being generated.
When PJP launches a process, it is not possible to observe the details of that process’s execution. This can be frustrating. The best way to get around this is usually to launch the process from TCL, but that doesn’t allow you to observe the effect of stacked inputs. Here is a way you can do that.
Let’s say that you have a process called MY.PROCESS which requires user inputs. Further, let’s say that you’ve set up the following stacked inputs in the PJP Process Detail Screen:
01.
Y
02.
2
03.
Y
04.
@ENTER
Further, let’s say it’s not working right, and you can’t figure out why.
Here’s what you can do. Write, compile, and catalog the following program, calling it PJP.TROUBLESHOOT:
DATA
“Y”
DATA
“2”
DATA
“Y”
DATA
“”
EXECUTE
“MY.PROCESS”
This program is exactly the equivalent of running the process from the main phantom program. Now run PJP.TROUBLESHOOT from TCL and you’ll be able to evaluate how the program is running and its usage of the stacked inputs.
Copyright 2011, Cubs Consulting, Inc.