Re: Runqry xxx PRTDEV(PRT03) doesn't work?

What works for me is
1. OVRPRTF vs. the QPQUPRFIL or some name like that spool file name that
queries end up being called on WRKSPLF unless you change that name via the
OVERPRTF.
2. The various RUNQRY that you want to apply the OVRPRTF against.

The challenge has to do with the sequence of over-rides of where printer
output is supposed to go.  Down below is a reprint of my old FAQ notes on
"Where did my report go & what overrides what with respect to redirecting it
some place else?"

> Subj:  Runqry xxx PRTDEV(PRT03) doesn't work?
>  From:    oliver.wenzel@cibavision.novartis.com
>
>  I'm trying to direct a query to a specific printer, but it always is
>  directed to PRT01. Why does above statement
>  not work?
>
>  Oliver

If we use 100% defaults, which we do not, where I work, then the bottom line
rule is

DSPSYSVAL QPRTDEV
This is the system value that says our system printer is PRT02 ... everything
is to go there unless something overrules that.  When we see something saying
PRTDEV(*SYSVAL) that means check the system values & use whatever is there.
System Values are about 120 rules that govern everything that runs on AS/400.
 You can WRKSYSVAL then select a category & find interesting one & 5-view it
current setting & choices & F1 help explanation.  I plan to be changing some
of them due to my security review & the last ones I changed were due to my
performance review.

The next level of over-rides is at the Device definition level ... there is
tons of stuff that we barely understand & frankly I basically want to concern
myself here with IS THE EQUIPMENT WORKING & handle any over-rides at a higher
level.  If you see something like OUTQ(*DEV) that means use whatever default
is setup in the device configuration.  There is a way to tie a particular
display station to have its output go to a particular printer.

Device rules can override System Values.

The next level of over-rides is at the Work Station Device Address
Description ... If you ever see something (*WRKSTN) that means it is saying
to use whatever rules are set at this level, which could point to something
else.

BPCS pop-up menu option-1 gives easy way to futz with that data, so basically
those rules work, so long as there are no over-rides.   There is a lot of
stuff here that we should not be messing with, assuming we want BPCS to work
right for us.  There are IBM commands to view this, but I think the BPCS
access is the best for most of our users.  The key issues for our users are
which printer is my stuff to go to, which jobq am I using, and should
anything be on hold?

Device rules can override System Values.
Work station rules can override Device rules.

User profile is usually only messed with by Security setup, but perhaps we
need a little program similar to the BPCS pop-up 1 because User rules can
override work station rules.  This would benefit people who move around
within one office to a variety of work stations that may have different
settings.  Within DSPUSRPRF (default your profile) & CHGPRF (changes to your
profile) you may see something like *WRKSTN meaning to use work station rules
for that scenario & we might want to change PRTDEV here to use your favorite
printer regardless of which work station you sign onto at which facility,
remembering that this also applies when you travel to another facility.

I am thinking that eventually I may wish to have OS4 type functions intended
for end users to change rules for their sign-on that do not impact their BPCS
access.

Change Password
Overrule Workstation Address rules - me regardless
Display what stuff is currently running in my name from anywhere on the system

DSPJOBD defaults to the 400 job description for your current sign-on session
which has been setup to be BPCS rules that apply to all BPCS users - slightly
different one for test environment - stuff in here includes library list &
also what printer & JOBQ & etc. & it had better have pointers to *USRPRF or
*WRKSTN so that this kind of thing can continue to be tailored by user or
work station.

Device configuration rules can override System Values.
Work station address rules can override Device rules.
User sign-on rules can override Work station rules.
Job Description rules can override User profile rules.

Several programs that output special forms, such as JT05, invoices, checks,
etc. have what is called a printer device file, which spells out the
dimensions of the forms ... page size, whether we need special alignment, and
many of the values in there can default to *JOBD (BPCS defaults) or lower
*USRPRF *WRKSTN etc. or do an override, to say ... we do not care who
generates this in the company, we want all of it to go to a particular
printer.

To a certain extent this is under the control of the programmer, but once the
program objects are compiled, we can CHGPRTF change that object to a set of
standards we wish to impose & in fact I have written several CL to impose
standards on JT05 after each software update, to make sure I never overlook
certain basics.

Query fits into this via QPQUPRFIL or something like that, where the rules
are set by whoever created the query, so if someone defined a query to say
"print this query ... do not put it on hold" that overrides anything the end
user had defined through BPCS for their defaults.

Device configuration rules can override System Values.
Work station address rules can override Device rules.
User sign-on rules can override Work station rules.
Job Description rules can override User profile rules.
Printer Device File can override Job Description.

This in turn can be overriden by the CL program that runs the job.
If you look in the QCLSRC for CIIIQUERY & 5-browse some of the RUNQRY there,
you will occasionally find a line just above RUNQRY saying OVRPRTF which is
an over-ride printer device file, where I can impose some stuff like

... I do not care what the query writer says, put this sucker on hold & let's
give it a NAME on spool file that provides a clue as to WHAT it is. so if
there are a ton of queries you can distinquish between them.

Some of what I just said was SOMEWHAT familiar to me - the class got into
some nuances I had not previously correlated, while the material is probably
rather alien to many power users.  The important stuff is

1) We can override work station printer defaults at the user profile level.
  In the short term Al Security adjustments.
  Longer term think about a program for users to adjust what is safe
themselves.

2) There are many elements of what can be over-ridden at various levels &
this hierarchy is important to stay aware of.

3) Most RUNQRY CL does NOT have any printer over-ride but when Al includes,
usually does put it on hold.

MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)