|
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)
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.