| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1196.1 | More information... | IOSG::NEWLAND | Richard Newland, IOSG, REO1-D/4A | Thu Aug 06 1992 15:37 | 12 |
| 1. What type of documents are being printed (e.g ASCII, WPS-PLUS, etc.)?
Does the problem only occur with some types of documents?
2. What printer destination is being used?
3. Is foreground or background formatting being used?
4. Are the print or formatter jobs being created? It could be hanging
in the Queue Manager during the creation of the job.
Richard.
|
| 1196.2 | customized print option? | SKNNER::SKINNER | I'm doing my EARS | Thu Aug 06 1992 16:19 | 15 |
| Is there any possibility that the user is actually using XP (multiple print)?
If so, I have seen a case where a customization to XP caused the logic's RFA
symbol to be cleared WITHIN the loop instead of once BEFORE the loop. This
caused the same RFA to be selected over and over. But the user would have
probably seen the same document keep printing, so that's probably not it.
But just in case it is a customization, does ALLIN1/NOCUSTOM make Print from
the index behave?
You should be able to see the condition causing the loop if you turn on script
and symbol tracing to the terminal for the problem users. Turn on the trace
after the user is on the index form and have "selected" the document to limit
the trace to only the Print code.
/Marty
|
| 1196.3 | More info | SWETSC::WESTERBACK | Mimsy were the borogroves | Fri Aug 07 1992 10:13 | 18 |
| More info from customer:
This occurs when printing regular WPS-PLUS documents, using
printer type LN03, background formatting. The job is printed, so
it seems it does not hang in the queue manager? Or could it
hang there even if it is printed?
They have very few customizations, but the problem with testing
ALLIN1/NOCUSTOM or trace is that this happens very irregularly.
Sometimes a month passes when all is OK, then it shows up again.
It seems they have had this problem since upgrading to 2.4.
Difficult to troubleshoot, it seems. Is there anything we could
tell them to check the next time this occurs?
Thanks,
Hans
|
| 1196.4 | Probably not Queue Manager | IOSG::NEWLAND | Richard Newland, IOSG, REO1-D/4A | Fri Aug 07 1992 11:00 | 18 |
| If the print job completes normally then the problem is unlikely to be with
the queue manager.
It may be useful to find out where the process which is running ALL-IN-1 is
hanging. Do the following when the problem occurs.
1. From another terminal on the same node find out the process id of
the hung process.
2. Do a $SHOW PROCESS/CONT/ID=<id>
3. Note the State and Current PC.
4. Use the PC and a Link map of OA$MAIN to determine where the process
is hanging.
Richard
|
| 1196.5 | Politically Correct? | SWETSC::WESTERBACK | Mimsy were the borogroves | Fri Aug 07 1992 14:15 | 8 |
| Thanks Richard,
I will convey this to the customer. Just a question, as I'm not very
familiar with link maps and PC: Do they have to have a link map from
the previous link, or can they relink after this error occurs to get
the map? Or does this give different PC's? (What does PC mean BTW?)
Hans
|
| 1196.6 | Ideologically sound? | IOSG::PYE | Graham - ALL-IN-1 Sorcerer's Apprentice | Fri Aug 07 1992 14:20 | 10 |
| As long as they haven't done anything that might have chnaged the link,
like adding modules into SITELINK or changing VMS versions or other
layered products, then it should be OK. It would be preferable to get
the numbers again after getting the map (and using the newly linked
image of course!)
PC = Program Counter i.e. whereabouts in the code the CPU is currently
pointing when it hangs/loops.
Graham
|