PJP Documentation > Reference Manual Menu
Please click on the links below for answers to each of the questions:
·
Why won’t
the console won’t let me launch a specific phantom?
·
Do the processes
execute in their own separate phantoms?
·
What is the
difference between “stop” and “kill”?
·
Why was the phantom
hung and then it recovered?
·
Why are all of the
phantoms hung?
·
What if we have
logons in different time zones?
·
Can we run
Cubs Menu options in a phantom?
·
Can we run multiple scheduled
instances of the same process in a single phantom?
·
Stacked inputs aren’t
working as we expected them to.
What could be wrong?
·
Why is
routing to the printer not working as expected for dayend
processing?
·
Why does my process
work from TCL, but not from the phantom?
·
How can I
inhibit “Phantom stopped” messages from coming up in the Phantom
Console?
·
Why does the
process status contradict the phantom status?
Typically this question arises when you are logged onto one logon, trying to launch a phantom which runs in another logon. You must be logged onto the same logon in which the phantom that you are trying to launch is set up to be run.
Another way that this question has been asked is, “Do the phantoms spawn new phantoms when a process is launched?”
The answer is “No”. There is only one system phantom port spawned for each PJP defined phantom. The processes within a phantom are executed serially within that port. If a process runs over the time that the launch of the next process is due, the second process must wait until the first process is completed. For that reason, if the timing of the launch of a process is critical, care should be taken about scheduling any jobs to run before it.
These are both ways terminate the execution of a phantom.
“Stop” is an orderly method, whereby the phantom is requested to stop itself. If everything is working correctly, the phantom will terminate shortly after a “Stop” command and will reset its status to “Stopped”.
However, sometimes a phantom is terminated by the operating system and is not executing, even though the PJP system thinks it should be. Eventually, after the phantom hasn’t checked in for a while, PJP considers the phantom to be “Hung”. Once a phantom has been recognized as hung, it must be “Killed” to reset the PJP database.
Bottom line: Always attempt an orderly “Stop” if you think there is any chance that the phantom is still running. The system is programmed so that 10 minutes after a stop request, if the phantom hasn’t stopped itself, it is recognized as “Hung”. At that point, the only thing to do is to “Kill” it.
Phantoms are considered hung when one of 4 situations is detected by the PHANTOM.MONITOR program:
- A process is running but the length of time since it was launched has exceeded its maximum run time.
- There is no process running and the phantom hasn’t checked in for more than 10 minutes.
- A stop has been requested for a phantom more than 10 minutes ago, but it still hasn’t stopped.
- There is a background process running which is meant to run continually and it hasn’t checked in for more than 10 minutes.
There are several possible explanations for why a phantom recovered once it was detected as hung. They are:
- A process ran for longer than its previously defined maximum run time. Once it returned, the defined maximum run time was increased to reflect this latest run time.
- In Spring, the conversion to daylight savings time creates a “lost” hour. This has caused phantoms to be falsely detected as hung.
- Sometimes, an exceptionally large processing load on the host server will keep the phantom from checking in for more than 10 minutes. If the PHANTOM.MONITOR program happens to get the system resources to run before the phantom has a chance to check in, a false “hung” situation is detected.
- Running logons on different time zones within the same PJP database can cause phantoms in the earlier time zone to be falsely detected as hung.
This happens after an unplanned stoppage of the host computer. The way to recover from this is to kill all of the hung phantoms and then launch them.
This has proven to be a problem on one of our client’s host computers. It led to false hung messages referring to the logon in an earlier time zone. For example, if the hourly PHANTOM.MONITOR program runs at 9:00 PM in a logon using PST, and it sees that a phantom running on a logon in MST last checked in at 7:59 PM, it will falsely conclude that that phantom is hung since it hasn’t (apparently) checked in for the past 61 minutes. Actually, that phantom checked in just 1 minute ago.
Normally, with all logons running in the same time zone, all logons share a common set of PJP files. However, in order to accommodate multiple time zones, the PJP system must be configured with separate databases and separate scheduled runs of the PHANTOM.MONITOR program for each time zone.
Yes, and No. Most Cubs menu options execute a pseudo-programming language called “proc” and require user inputs prior to doing any work. Since almost all of Cubs’ procs clear the input buffer prior to executing, any stacked inputs that you set up in the Process Detail Screen in the Phantom Console will be thrown away by the Cubs proc. Because of this, it is almost always necessary to minimally (at least) customize any Cubs standard menu items which you may wish to run from the Phantom Job Processor.
Another issue which will prevent you from running a Cubs process from the PJP is if the Cubs process needs to get security information from the logged on port. This is because there is not a port logged on to Cubs for a process executing under the PJP system. For example, you can’t perform transaction posting from within a process running as a phantom.
Yes, but you need to “trick” the system. One of the unchangeable constraints of the PJP system is that the “run instruction” can’t be repeated within a phantom’s list of processes. Sometimes, it is necessary to have the same process with more than one scheduled cycle. In order to do that, you will need to somewhat modify the run instruction. Let’s say, for example, you want to execute the PL program MY.PROGRAM in multiple cycles. Here are some different run instructions that you might use:
RUN PL MY.PROGRAM
MY.PROGRAM
MY.PROGRAM 1
MY.PROGRAM 2
The second one (MY.PROGRAM) makes use of the cataloged version of the program. The last 2 make use of execution parameters, which need not be used by the program, but which only serve to make the run instruction unique. Therefore, you may schedule an unlimited number of iterations of the same program.
Under some circumstances, the process being called in the run instruction could be corrupting the input buffer, making the stacked inputs behave badly. Click here for a complete explanation.
With version 1.03 of the Phantom Job Processor, we introduced the ability to configure printer specifications at the Phantom level. Previous to that, the PHANTOM-DAYEND program used its own printer specification from the CODES file, PHANTOM-DAYEND-OPTIONS item. We should have removed that functionality from the dayend options with the introduction of the Phantom level printer specification, but we didn’t. We will remove it from the next software release.
In the meantime, please understand that the dayend processing will overwrite the Phantom printer assignment with the printer as specified in the CODES file, PHANTOM-DAYEND-OPTIONS item. By modifying that item to route output to the correct printer, everything should work as expected.
The best way to troubleshoot a process which fails under the phantom is to execute that process from TCL. However, sometimes a process works well from TCL but still fails when run by the phantom. Here are a some possible things to look for:
- Does your process execute some Cubs programs which require port security checks (i.e. BLIB POST)? Since the PJP phantom port has evaded Cubs front-end logon dance, port security will sometimes stop execution.
- Does your process need to detect the current Cubs account name? Most Cubs programs use the sub-routine WHO.CUBS to detect the current logon. In UniVerse systems, when a process is run as a phantom, the WHO.CUBS program returns the logon name “phantom”. In this case, using OCONV(“0”, “U50BB”), instead of WHO.CUBS, to detect the logon in your Basic program will fix the problem.
- You can run your phantom as a regular process from TCL by entering PHANTOM.DRIVER LOGON*PHANTOM_NAME. Where LOGON is the name of your logon and PHANTOM_NAME is the name of your phantom within that logon. If you just let it run, it may give you some hints, on the screen, about why it is failing. Please make sure that if you do this, the same phantom is not running as a regular phantom. That could cause trouble.
If the 3 suggestions above don’t clear up the issue for you, the best thing to do is to have your programmer insert code within your process to build a log to a disk file of internal logical steps. It may take several iterations, but eventually you will be able to locate the point of failure and fix it, whatever it is.
In UniVerse, “NOTIFY” is a configurable setting. When UniVerse is initialized, it is set to NOTIFY OFF. Some systems, as part of the logon process, set it to NOTIFY ON. If it is set to NOTIFY ON, you will get messages from your phantoms while you are within the Phantom Console screen and your screen will get corrupted. From TCL, you can enter “NOTIFY OFF” and it will stop that behavior. However, if the problem persists the next time you log on, talk to your system administrator to see why NOTIFY ON is being set by your logon procedures.
On the Phantom Console main screen, the status listing is the most current status for each phantom. On the phantom detail screen, embedded in the list of processes, is the most recent status for each of the processes. Sometimes these statuses contradict each other which leads to confusion. Please remember that the status on the main screen is the real one.
Here’s an example which came up recently. Dayend was running last night when the host computer crashed. Once the computer came back up, all of the phantoms were hung, so the admin killed them and then launched them. After all that, the status on the main screen was “Waiting to launch PHANTOM-DAYEND at...” while the process status on the phantom detail screen said that the PHANTOM-DAYEND process was “Running”. The “Waiting to launch” status was the truth. The “Running” status was merely the most recent historical status for that process. Since it didn’t complete, it never got set to “Done”.
Copyright 2010, Cubs Consulting, Inc.