Re: Remote printer problem

Your tale of reports seemingly jumping to random drawers other than the 
intended ones reminded me of similar history at Central.

We had a similar problem when we first got IBM 4247 which supports 2 drawers.
There were several issues that had to be resolved.

I found it neccessary to add a program to the start-up sign-on, so that when 
people sign onto the M/36 reality, it defaults the user identity to the 
appropriate corporate printer drawer, then have particular programs printer 
files tie particular form types to particular drawers, and when we have 
multi-drawer printers in more than one facility, consistently assign 
particular drawers to particular forms ... one part paper / factory job 
tickets / etc. always go in a particular drawer globablly within the company.

This is because we have people helping each other across facilities in the 
same kind of department ... a facility is understaffed in a particular 
department due to vacations or sickness or something, so folks who understand 
the application generate everything that is needed, then at the last step 
move it to the relevant printer, at which point you want defaults to be 
consistent across facilities.

Reports use many defaults & sometimes software has been written for a 
different reality, inadvertently over-riding what we now seek, thanks to 
adding hardware or OS featues that we previously never had occasion to use.

From IBM classes I learn that (& this might not be the whole story) ... well 
at the bottom of this post to you is a copy (with a bit snipped out) of 
something I recently shared with some power user help desk co-workers.  My 
focus on what overrides what overrides what ... was from the issue of "Where 
is my report?" but you can use the same general path to find "What is telling 
it which drawer to use?"

We were periodically on M/36 owning the hardware, so the 4247 had to emulate 
a type of printer the M/36 recognized and was also capable of using the 4247 
features.  It turned out that we needed microcode patches for the 4247 for 
M/36.

In more recent times our problems have been with the use of PC printers 
attached to twinax monitors, in which the emulation has to be one that the 
monitor supports, and  also can handle the kinds of printing we are doing ... 
the printer can do it, the problem is that the printer it is emulating can 
not.

>  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 ... 
> 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 am currently studying implications of changing some of them 
> due to my security review & the last ones that
> I changed were due to my performance review.
> If you WRKSYSVAL F4 *PRINT you get a nice chart showing original values 
> as shipped from IBM vs. those we have changed to something else.
>  
>  The next level of over-rides is at the Device definition level ... there 
are
> 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?
>
> Occasionally & unfortunately we sometimes have users who lack the 
> 400 computer literacy skills to comprehend this topic, let alone
> manage this properly.  BPCS security can lock them out of pop-up-1
> which resets values for the current work station they signed on as
> & for serving their needs, power users can use the option on main SYS menu
> in which it prompts you for which WRKSTN address we need to reset rules for.
>  
>  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.

> Let's suppose some of our highly mobile users want to use this feature,
> but do not want to have to remember what to change every time they visit
> another office ... we could use a variation on how we handled BPCS/36
> facilities where people had to sign on like AL.LAW 
> to access the LAW data base, or AL.GWD for the GWD data base,
> or today I use AL for the regular enviroment & ALE for the educational
> & test environment.  When you are physically at a particular office,
> sign on with the user-id issued to you that has been optimized for
> printer you want to use at that office.  I do not like this approach
> due to flaws in BPCS security management & the complicated
> task of counting real users for license management.
> I will be thinking about alternatives here ... ideally for end user
> some menu option they run that says "reset my defaults for me
> working in ______ fill in which facility that you want your reports
> to go TO as opposed to WHERE you physically are now"
>  
>  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, similar to other general functions on some
> of our user menus today.
>  
>  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.
>  
>  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 simple CL to impose standards on JT05 
> and other special reports after each DDS 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 on a particular printer & do not put it on hold" 
>  that overrides anything the end user of the query had defined
>  through BPCS for their standard defaults.

Somewhere in here, and I am not exactly sure where, are defaults for the 
spool 
ie. info associated with WRKOUTQ, that say what to do with all reports that 
are sitting in that outq, in the absense of any overrides to these defaults.  
This has been an issue for us with software that violates our page size ... 
we use 68 lines / page at 8 lines to inch, which is much more user friendly 
handling the paper than the standard sizes that far too much software assumes 
everyone uses.

>  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 creator 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.

> Summary Chart to help remember what overrides what
> =======================================
>  Where 100% defaults still in effect - check System Values.
>  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 & Query can override Job Description.
>  CL program off of Menu can override the above.
>  User at WRKSPLF can change the rules before releasing to print report.

Now what is missing from Al's picture?

> The important stuff that we might want to do differently in the future 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.  I intend to cut / paste into 
> a Word document, then add that to our notebook on system values.
>  
>  3) Most RUNQRY CL does NOT have any printer over-ride 
> but when Al includes, usually does put it on hold.

Alister William Macintyre 
Computer Data Janitor etc. of BPCS 405 CD Rel-02 on 400 model 170 OS4 V4R3 
(forerunner to IBM e-Server i-Series 400)  @ http://www.cen-elec.com Central 
Industries of Indiana--->Quality manufacturer of wire harnesses and 
electrical sub-assemblies

+---
| 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
+---