Re: Suppressing Compile prints

["Cheri Duchrow" <cduchrow@xxxxxxxxxxxxxx>]

Bill

Buck had a good suggestion and here is another one.
If you go to Windows/Preferences/Remote Systems/iSeries and select Command 
Execution.
There is a section for compiles that allows you to
select a job description to use when compiling with WDSc.  The default is 
for *usrprf but you could set up one for the developers and they would need 
to change this setting to the job description you setup that would send 
output to a que that wasn't attached to a printer.

Here we have a job description for developers and it is attached to our user 
profile so we can keep it at *usrprf.  I know that is not always possible.

Cheri
"Buck" <kc2hiz@xxxxxxxxx> wrote in message 
news:f9aio6$tof$1@xxxxxxxxxxxxxxxxxxxxxx
> Bill Barnes wrote:
> > Thanks to all for the suggestions.  I didn't make myself clear.  I don't
> > care if the compile goes to an outq.  I would like to know how to
> > redirect it so that anyone compiling in RSE would go to a non-printer
> > attached outq.  I don't want to have to redirect each time or to
> > remember to prompt and change the printer outq.  My compiles in batch go
> > to my own outq and I can redirect to a printer if I desire. (Rare)
>
> Hi Bill,
>
> WDSC uses native System i user profile and spooling functionality.  Each
> RSE user would have her compile listings go to the OUTQ specified in her
> user profile.  If you want to set up RSE to override that behaviour you
> might look at the connection properties, subsystems tab.
>
> In RSE, right click on your machine name (connection)
>   Properties
>     Subsystems (left side)
>       iSeries Commands (right side)
>
> There is a place you can put an initial command.  You can write a
> command that will call a CL program to test the user profile and CHGJOB
> OUTQ() accordingly.  This would be a good plan if you feel there are
> several things about the System i environment you want to set.  Another
> thought is to put in OVRPRTF *PRTF OUTQ(nnn) or HOLD(*YES).
>
> Another thought is to call the user's initial program, which might be an
> issue if it wants to bring up a menu.  You can overcome that problem by
> making a tiny change to the initial program.  Test (RTVJOBA TYPE()) if
> the initial program is running in batch or interactively.  If
> interactively, do everything.  If batch, skip the menu.
>
>   --buck