• Subject: Re: Shared printers:
  • From: MacWheel99@xxxxxxx
  • Date: Tue, 26 Dec 2000 18:21:40 EST

I do not have exactly your situation but have had several things similar.
We had to do SOME user training but we also did some modifications to keep to 
an absolute minimum the user training needed.  
The name of the game is ... automate whatever can be done to help these 
people, then pick what they need to know to make it work that is the minimum 
fuss & bother for them to have to remember.

The user training needed was to have them WAIT until the 400 is ASKING them 
to put some forms in before they ACTUALLY put those forms in, and to NOT 
respond to printer messages unless you are ACTUALLY at the printer, and also 
never to ASSUME that a message is the one they get the most often - always 
dive into the detail behind the messages.

This avoided trying to explain JOBQ & automatic audit trails of normal work 
to those people who were running around the office asking co-workers to not 
send anything to the printer until they got done doing their special forms & 
it also stopped people responding to printer messages conceptually in 
conflict with whoever was trying to get the printer to do something contrary 
to the remote person unerstanding.

By not puting the new forms in until the 400 was ASKING for them, the printer 
was in the position of being OWNED by that report, so even if something else 
came along with higher priority, it still waited until the current report was 
resolved.

To make life easier for all printer users, there is a 400 display station in 
close proximity to system printers at each site that is designated as the 
console for that printer, so that people have minimum walk distance between 
printer line-up adjusting & 400 retry that page or do another line one at a 
time.

To make life easier for people who are at the bottom of the 400 literate 
scale, we have menu options to check on their reports & what is in their 
JOBQ, and special forms reports go on automatic hold but high priority in the 
spool file, so that when they are released to print they are on the top.  We 
have not been doing this with all reports, just when they are identified as 
being used by people who are 400 impaired & could use this added help.

We also explored separate JOBQ for some people whose only jobs are generally 
pretty fast.  Reason ... 90% of time they know how long job should take, but 
once in a blue moon gets behind a job that will take a while, so they think 
their job is done & they take the next step when their job is still in the Q.

A lot of the problems with newcomers to 400 are people whose only computer 
background is home PC single threaded activity.  They think in terms of push 
a button on a menu & their report should be instantaneously on the printer.  
They do not understand printer sharing & JOBQ logic.  

Likewise they are at a printer & they know that it can be shared by everyone 
in the company but this falls out of their brain & they assume for the moment 
that the only people able to use it are those individuals in ear shot of 
their request to stay off the printer until they are done with their special 
forms.

We used to have a real big problem with people who deal with situations using 
... "when this happens" you take a C then another C then an R except 99% of 
the time what actually happens is something for which that only converts an 
easily solved mess into a mess of catastrophic proportions, because the user 
involved really does not understand the 400 or the application.  

People with instruction sets that read take option 5 then 3 then 1 are doomed 
when someone adds something to a menu, or their starting point is not the 
menu the instructions were written for.  But from time to time in my 
computing career I have had co-workers who see nothing wrong with this.

We also have printer with multiple drawers, permanently loaded with different 
form types.  We found it expedient to have a program embedded in everyone 
sign on that defaults their reports to a particular drawer, and then specifc 
form types are sent to the other drawer by their CL.

> From: mpatee@abm.com (Matt Patee)
  
>  Situation:
>  
>  I've got a 730 AS/400 V4R4M0, and an HP9000 HPUX V11. I'm using an IPDS
>  capable printer (printronix line printer). AS/400 uses IPDS or PJL to print
>  to the printer, HP uses LPR/LPD. Both systems work perfectly alone. The
>  problem I am having is when multiple form types are used on one printer
>  shared by both systems, we run the risk of the other system overwriting the
>  form type.
>  
>  Example:
>  
>  Standard paper is loaded on the printer with no print jobs pending. A user
>  wants to print some invoices onto this printer, and changes the paper
>  (knowing that the 400 is smart enough to ask her to load a new form type
>  with her invoices). However, just after she loads the paper, and before she
>  prints her report, a Unix user send a standard print job to the same
>  printer. Because of the different spooler, it doesn't know that the form
>  type has changed and prints the standard report on the invoice paper.
>  
>  HELP!
>  
>  I need to know how people are solving this problem. Obviously training the
>  users is an option (but I don't want to do this). Can the 400 accept HP
>  print jobs, and retain security and settings for number of copies etc? Does
>  the HP spooler do this with 400 jobs? Is there a third party spooler we
>  could use to accomplish this? What if any other solutions are there? I know
>  my company can't be the only one out there facing this problem. Any help or
>  suggestions would be very appreciated.
>  
>  
>  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>  Matthew Patee
>  Midrange Systems Manager
>  ABM Industries
>  (415) 836-9909
>  fax:(415) 836-9911


MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
AS/400 Data Manager & Programmer for BPCS 405 CD Rel-02 mixed mode (twinax 
interactive & batch) @ http://www.cen-elec.com Central Industries of 
Indiana--->Quality manufacturer of wire harnesses and electrical 
sub-assemblies - fax # 812-424-6838

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

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.