Re: Compile Printing -- WDSCI-L

I suspect that the issue is that the job QPRTJOB where the output is spooled is really under QUSER, which probably has its output going to outq PRT01, and PRT01 actually has an active printer attached to it in Bill's shop. The simple fix is probably to change QUSER, since I doubt that Bill wants to figure out what would be affected by not having an active printer on PRT01. (I was always told not to connect an active printer to PRT01, precisely because IBM user profiles point to it, resulting in issues like this one. I doubt that everyone got that message, though.)

Anyway, Bill, check QUSER and see if that is the problem. If it is, changing its outq should work and is an easy, global fix (although you may have to do it again after operating system upgrades and such). It's worth a try, anyway.

Dave Shaw
Mohawk Industries

"Buck" <kc2hiz@xxxxxxxxx> wrote in message news:<f9co9s$tar$1@xxxxxxxxxxxxxxxxxxx>...

Bill Barnes wrote:

I am missing something here. Each programmer has an OUTQ and compiling
in Batch or interactive causes the compiles to go to their specific
OUTQ. In RSE I have checked to see if it says *USRPRF and it does. Yet
the compiles running in the RSE subsystem go to an active printer. At
first it wasn't too bad because there was a forms change message and the
printout could be deleted but, somebody decided to answer the message
and now the compiles just whiz right through. I have switched back to
compile in batch which is OK most of the time except when someone is
running a job in QPGMR and the compile gets held up and I don't realize
it and can't figure out why my changes didn't work.

It sounds a lot as though there is a discrepancy between your RSE
session and your batch user profile. Let's have a look at the RSE session.

Start WDSC. Open an RSE perspective. Open an iSeries Commands Log
view. In the command bar at the bottom, on the right side is a place
you can enter an OS400 command. Try dspjob output(*print) and look at
the resulting output to figure out what user profile, etc. is in use.
That command log is basically the job log of the job that WDSC starts to
do System i tasks.

Is there a good reason why so many things in RSE are so difficult to
figure out?

I'm not ruling out an RSE issue but this looks quite a lot like a
standard System i work management question. Let's see what the dspjob
says. Once you get the listing, you can go to a command line and look
at the full job log of that job to see if there are any clues there.
Here, this resulted in a job like this: dspjob 111445/quser/QZRCSRVS

One possible clue would be that the outq is not found and the default
printer was used instead. That could happen if the library list isn't
right. THAT could happen if your library list is typically set by the
initial program (which does not run unless you are signing on to an
interactive session.)
--buck