Re: Default printer

I shall assume that your system was working fine until you got PRT01 auto 
create, implying that the 3rd party software is doing some command some place 
"if PRT01 exists send it there, else ..." so the immediate work around is to 
change the name of PRT01 to something else via WRKDEVD or WRKCFGSTS but the 
problem will reappear with next printer auto create.

Here is cut & paste from a nold post by me "why is my report where?" which 
may give you some insight into your options - I edited a few points where it 
seemed relevant to your situation

Now lets review what overrules what to send print outs where.

An important significance of being able to navigate this stuff is where the 
AS/400 gets its instructions from & what overides what defaults in 
determining where to put my report ... we often have users who create a 
report, it prints on the wrong printer, they cannot find it ... they have 
settings they comfortable with, everything working good, go to some other 
work station & problems.

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

DSPSYSVAL QPRTDEV 
This is the system value that says our system printer is PRT02 or yours is 
PRT01 ... 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 periodically change a few due to security review & 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, which 
sometimes has value at the department level.

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     BP[CS 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 
profitl) 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.

Your 3rd party software may well have a JOBD much like our BPCS does, in 
which you might want to change its rules from PRT01 or the system value to 
*WRKSTN

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, which once upon a time we were doing with acknowlegements of changes 
to customer orders ... print them all in the sales department so they would 
see any unauthorized changes ... I had suggested we modify acknowlegements to 
include WHO keyed the changes.

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.

There is also a command, but I forget its name, in which you can change all 
the PRTF objects in a library or a group of libraries to some new rule, but 
you have to factor in what impact an OS/400 upgrade might have on this.

Query/400 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.

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)

> From: m1c@ingersoll-imc.com (Condon, Mike, /m1c)
>  
>  I have some applications that are causing problems printing. We really 
> only  have one true "printer" (an autocreated PRT01) on our system. 
> All other printing is done by 
>  remote outq to HP Jetdirect printers. The problem is some programs (3rd
>  party) are printing to this printer by default, 
>  although the user profiles are all set  up with 
>  PRTDEV *WRKSTN, and their print queues are set up just fine. Is there any
>  way around this?




+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---