PSF/6000: Operational problems when printing to a 3827
ITEM: RTA000098009
Q:
ABSTRACT: Operational problems when printing to a 3827 from
PSF/6000.
SEARCH ARG: psf6000 queue
TOPIC THREAD: PRINT
PSF/AIX
..
My customer is experiencing some operational issues printing from
PSF/6000. This is the environment:
- Batch jobs running on an MVS host take data from MVS and other systems
and create a file which is sent via TCP/IP to PSF/6000 on a RISC.
This RISC is used exclusively as a PSF/6000 print server.
- PSF/6000 transforms these files to AFP and prints to a 3827.
We are trying to understand whether the issues are due to product
design, our customization/implementation of the product/process, or a
product defect. I'm not an AIX or PSF person, so please correct me if I
use incorrect terminology.
1. PRINT QUEUE GOES 'DOWN'
-----------------------
They notice that when the 3827 requires some type of intervention
(i.e. the printer needs hardware service, or printer out of paper,
or offline to another system), that at about 2 hours, the print
queues 'go down'.
a. Is there a way for the customer to control when and if the
print queues should 'go down' when there's device intervention?
b. If so, how?
c. If the customer has no control over this, are these occurrences
of queue down situations by 'design' or could we have a defect?
d. Under which situations/circumstances should we expect print
queues to 'go down'?
e. The customer claims that if the 3827 is in the middle of
printing a job when the queue goes down, after manually
restarting the queue, the job resumes printing FROM THE
BEGINNING of the job (i.e. not where it stopped when the queue
went down).
i.) Is this working correctly?
ii.) Does the customer have any control over whether the job
should restart from the beginning or where it left off
after a queue is restarted?
2. RISC REBOOT
-----------
9 out of 10 times after the print queue goes down they're able to
manually restart it. However, about 1 out of 10 times this manual
restart doesn't work and they have to reboot the RISC box. This
causes headaches because they have to rerun the MVS batch jobs and
retransmit to PSF/6000.
a. Have you heard of the need to reboot to restart queues? Does
this sound like a 'working as designed' or defect?
b. When they reboot, they are left with 'temporary' files in the
directory. In the past they've had problems when they haven't
cleaned up these files since they've taken a lot of disk space
and subsequent large files didn't have room to run. The
questions are:
i.) What are these temporary files? Are they print images?
In other words, after a reboot, instead of rerunning the
batch job at MVS and resending to PSF/6000, could these
temporary files somehow be requeued to the printer?
ii.) If so, how?
iii.) If not, what are these temporary files and how are they
used in the printing process?
3. Print Queue Down due to CE Service & Job Restart Questions
--------------------------------------------------------
Last week we had a situation where the 3827 required servicing due
to smudged printing. The CE came in to service the machine and at
the time it was not printing. However, the CE was not aware that
there were jobs in the queue which hadn't yet started printing.
The CE performed maintenance, which didn't take much time --
maybe 10 minutes. When the CE completed the repair action, the
customer noticed that the print queues had gone down. The customer
had to manually restart them.
a. Is this normal? I.E. if a CE services a 3827 when there are
jobs in the print queue but haven't started printing, should
this cause the print queues to go down?
b. If so, are there any operational procedures the Customer/CE
should take to prevent this from happening?
c. If the printer is in the middle of printing a job and the CE
needs to service the machine before the job has completed
printing, what should we expect to happen?
i.) Should we expect the queue to go down?
ii.) Should we expect the job to be placed on 'hold' until the
CE is done and then resume printing where it left off?
iii.)Should we expect the queue to remain up, but the job to
restart printing from the beginning of the job?
iv.) What procedures should we/CE put in place to ensure this
goes as smoothly as possible with the least amount of
're-processing'?
4. Where is the best place for us to read about and understand the
process from the time the RISC6000 receives the print file through
transformation, queue handling and printing?
Thanks in advance for your help. Looking very much forward to your
response as soon as possible... ¢¢¢ THANKS>>>
For background purposes, we are running PSF/6000 1.2 and also AIX 3.2.5.
Let me know if you need any additional info. Thanks.
A:
Let me give a little background first before answering your specific
questions. The architecture of AFP (Advanced Function Presentation)
is designed for robust printing environments and sophisticated error
recovery. To accomplish this, the driver software (Print Services
Facility or PSF, in this case PSF/6000) and the microcode in an IPDS
printer work together and maintain a two-way conversation whereby the
software is aware of the status of the printer and of the jobs that it
has sent to the printer. PSF/6000 also manages the print job resources
and keeps track of what is available in printer memory or what must be
sent down to print a particular job. If that two-way conversation is
broken or lost for any reason, then PSF/6000 has no way to know the
status of either a print job in progress or of the resources at the
printer; therefore, after a broken connection (including a time-out),
PSF/6000 will begin a job again, including downloading of resources
and restarting a queued job from the beginning. If, on the other hand,
a simple intervention like a paper jam or out-of-paper condition is
fixed without breaking the two-way conversation, then PSF/6000 knows
the status and can generally resume a print job at the point it stopped.
Note that this differs somewhat from PSF/MVS which can work with JES
checkpointing to resume printing from the most recent checkpoint if the
IPDS conversation is interrupted. There is no JES-like checkpointing
in AIX, so there is no similar capability in PSF/AIX.
Also note that you cannot daisy-chain multiple channel-attached printers
(like the 3827) off of a single S/370 Channel Emulator/A adapter; only
a single channel-attached printer per card is supported.
Starting with your last comment first, please be aware that PSF/6000
1.2 has been withdrawn for marketing (12/31/1995) and went out of
support 9/30/96. I would strongly encourage your customer to move to
InfoPrint Manager 3.1 (5648-B34).
For PSF/6000 1.2 today, please ensure that the customer has installed
the most recent maintenance, as there have been some important fixes
to the device driver for the S/370 Channel Emulator/A adapter. Please
follow the instructions that come with the PTFs carefully; for the
channel card fixes to take effect, the RS/6000 must be rebooted after
the PTFs have been loaded. Then you must reload the device driver on
to the S/370 Channel Emulator/A adapter through smit.
R1-a) Yes.
R1-b) This can be set in smit in the field for DEVICE INTERVENTION TIMER
under TUNING OPTIONS for Show/Change Characteristics of a Printer.
The default is 9999, which is to never time-out. Online Help for
these smit panels is quite good.
R1-c) Customer can control the timer.
R1-d) A PSF queue could go down for a number of reasons. Any reason
that causes the two-way IPDS conversation to be broken will take
the queue down. If the device intervention is set to a value other
than 9999 and expires, the conversation breaks. If someone powers
down the printer or disables the printer interface, the
conversation breaks. If you have the Job Interval SHUTDOWN timer
set so that the printer can be shared between more than PSF, when
the timer pops, the conversation will be broken. If PSF/AIX
encounters an unrecoverable condition (like out of disk space),
it will end the running processes and mark the queue down.
If the AIX spooling subsystem goes down, the queues will go down.
If you're sharing the printer between two PSFs and you switch the
printer between systems, the conversation will be broken.
Those are the most common that come to mind immediately, but this
is not an exhaustive list.
R1-e) This is working as designed; if the queue goes down, PSF/AIX loses
contact with the printer and cannot know the printer's or print
job's current status. Therefore, it must start over. The
customer cannot control this. Note that, as I mentioned above,
if there's a simple intervention condition that can be recovered
without the queue going down (like a paper jam or out of paper),
then once the intervention condition is fixed, the job should
resume printing from the point it stopped.
There is currently no forward-spacing support in PSF/AIX. However,
in December 1994, we began supplying (through a PTF) a program
called afpsplit that can extract a range of pages from an AFPDS
file for printing. Since your customer is printing PostScript,
they could run the ps2afp transform to create an AFPDS file and
then submit the resulting AFPDS file to print; then if there's any
kind of problem, they could use the afpsplit command against the
AFPDS file to extract the range of pages that need reprinting.
(You can also create AFPDS from PCL input, from pagedef-formatted
line data, from SAP R/3, or from a couple of other datastreams.)
| There *is* forwardspacing in InfoPrint for AIX (5648-B34). Please
| refer to the Salesmanual or announcement letter for additional
| information.
R2-a) The customer should not have to reboot the RS/6000 to restart
queues. Please ensure the latest device driver is installed for
the S/370 Channel Emulator/A adapter, and if this problem persists
open a PMR with the Support Center.
R2-b) I can't answer this one without additional information about these
files (what directory are they in and what are they called?).
R3-a) See the initial overview I provided. If the two-way IPDS
conversation is broken, the queues will go down and must be
manually restarted.
R3-b) I would recommend that the CE coordinate with the PSF Print
Administrator or operator so that the key jobs can be run
ahead of time and so that the operator takes the PSF queues
down in an orderly manner before the CE begins the PM.
If you know you have a major run coming up close to PM time,
work with the CE to schedule the PM just before the critical
run. I know of no way for the queues to be restarted
automatically; the operator will need to restart them.
R3-ci) Yes, as per previous discussion.
R3-cii) No, as per previous discussion. Neither AIX 3.2.5 nor PSF/6000
V1 has the capability to hold a job. AIX V4 has the capability
of holding a print job that has not yet started printing.
PSF for AIX V2 allows an operator to interrupt a job that is
currently printing and to resume it later.
R3-ciii) No, as per previous discussion. I would think that almost
anything the CE does at the printer will require him/her to
disable the channel or take the printer offline which will
break the two-way conversation.
R3-civ) See R3-b above.
R4) For PSF/6000 V1, there was a publication called PSF for Users of AIX
(G544-3814) that contained an introduction to the product. That
publication should have shipped with the product, so the customer
might have it in house. Or it can still be obtained in softcopy
format from the PENPUBS disk as part of the PSF6OLD PACKAGE or by
itself as G5443814 TERS3820. For PSF for AIX V2, the information
in that book was moved to the first chapter of Print
Administration. Information and hints for System Administrators
is contained in PSF Print Administration (S544-3817).
Thanks for using WWQ&A.
| Reviewed and updated Nov 1998.
S e a r c h - k e y w o r d s:
AIX PSF/6000 PSF QUEUE OPERATION 3827 INTERVENTION psf/aix channel
device driver timer ipds conversation forward forwardspace hold down
infoprint
WWQA: ITEM: RTA000098009 ITEM: RTA000098009
Dated: 11/1998 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:32
Comments or suggestions?
Contact us