PSF/AIX: Need to reprint range of pages with minimal operator intervention
ITEM: RTA000154853
Q:
Topic thread:
Printer Systems (PRINT - NA/ATS)
PSF/AIX
My customer needs to print range of pages and the idea is to automate
this process as much as possible. The afpsplit command needs an AFPDS
file to make this kind of function, could you please give some
orientation on how the shell script would work so that the end user (the
glass house operator) does not have to deal with acif.
Thank you in advance for your help.
A:
As we discussed last week, you have customers submitting print jobs
from both HP9000s/HPUX using lprafp and from MVS using the NPF feature
of TCP/IP for MVS V3. Jobs from both sources are processed by ACIF on
the RS/6000 before printing. Occasionally (on an exception basis),
these customers may need to print only part of a job (a range of pages),
and they'd like to automate this process as much as possible.
Keeping in mind that I am not a programmer and there may be something
I'm overlooking, here's what I envision might be able to be done with
custom programming. I'm assuming that the jobs can be resubmitted from
the remote host, either by the operator or the original submitter. (If
that's not the case, then I've given an alternative idea at the end of
the item.)
GENERAL OVERVIEW:
1) Since afpsplit only works on AFP files, the files from the remote
system must first be converted to AFP on the RS/6000, in your case
using ACIF.
2) Then the operator would be prompted to select the range of AFP pages
that need to be reprinted.
3) The values s/he keys in would be used as input to the afpsplit
command. Some calculation would be needed; see below.
4) The output of the afpsplit command would be an AFP file containing
the subset of pages specified. This file would then be submitted
to print.
That's the general process. To automate it will take programming to
create a custom shell script or program that would run as a backend
program on a new AIX print queue. What I don't know is what it will
take to capture the parameters passed from lprafp or NPF; it may be
quite straightforward, or (since both lprafp and NPF send jobs to AIX's
lpd) it may require accessing the related AIX qdaemon's Job Descriptor
File (JDF) to capture the parameters passed from the remote host. The
AIX print specialist in the ATS that I talked to said he suspects that
the AFP parameters would come in to as simple variable, which makes
it straightforward to catch them. However, it will take additional
effort to capture some of the qdaemon information (such as userid,
title, etc.) that is sent in the JDF. (See below for some reference
items that may provide some guidance.)
Again, I'm assuming for this scenario that the original job is
resubmitted from the remote host to this new AIX print queue that
I'll call "reprint".
The custom shell script/program would need to:
1) acif the job to create AFPDS, using the parameters passed by lprafp
or NPF (also need to capture any formdef name sent down for use at
print time)
2) Store the resulting AFPDS in a temporary file that is erased later
if the rest of the process is successful (requiring return code
checking)
2a) Optionally, if you want to get fancy, you could code in a command to
count and display the number of AFP pages in the temp file using the
command "afpdmp | grep -i bpg | wc -l" and return that
to the operator console with some explanatory text.
3) After acif completes successfully, echo/print a message to the
operator console "What is the first page you want to reprint?"
where "page" is the nth AFP page in the job, not necessarily related
to any page number that might appear in the data. Some calculation
would be needed because of the way the starting page number is
specified on the flag (i.e., if you want to start on page 21, you
specify "20" on the -f flag). See the syntax of the afpsplit command
for additional information. Capture the operator's response to
a variable that will be used when specifying the -f flag on the
afpsplit command. You could code in logic to either require a
number here (make the operator specify it even if it's page 1) or
to check and see whether or not the operator specifies a value; if
not, then start the afpsplit at the beginning.
4) Echo/print a message to the operator console "How many pages do you
you want to reprint?" or, if you want to code in the calculations,
"What is the last page you want to reprint?", again where "page is
the nth AFP page in the job, not necessarily related to any page
number that might appear in the data. Capture the operator's
response to a variable that will be used when specifying the -p flag
on the afpsplit command. Again, see the syntax of the afpsplit
command for additional information.
5) Taking the values captured in steps 3 and 4 above, build an afpsplit
command against the temporary file and pipe the output to the enq
command along with any non-acif parameters (like the formdef name)
that were passed from lprafp or NPF. Build in logic to handle it if
there are no such parameters. (If you want to pass it to the psfin
command instead, then you'll have to build a job script dynamically,
then erase it. The advantage of psfin is that you'll be using Input
Manager with its segmenting and other advantages. The disadvantage
will be that it increases the complexity of your custom backend.)
6) If all completes successfully (rc=0), erase the temporary file (or
you could specify the -r flag on the enq command in step 5). If it
does not complete successfully, figure out how you want to handle
the possible errors.
If it's not possible for the operator or the original user to resubmit
the job from the original platform, then you may need to consider an
AIX queue to which all lprafp or NPF jobs are sent; this AIX queue would
have a custom backend program or shell script that first makes a copy
of the incoming data and parameters somewhere and then prints the
original data with the parameters. Then, at a later date, if it's
decided a subset of this job must be reprinted, you'll already have
the original data and parameters on the RS/6000. You'd have to come
up with some naming convention so you would be able to find the data
at a later time if needed, and you would also have to erase the copies
if and when they're no longer needed.
If you wish to contract with AIX Advanced Technical Support, the print
specialist could write a custom program for you for a fee. However,
he has also put a great deal of helpful information on an internal
web site that would give you an excellent start.
http://tesch.aix.dfw.ibm.com/printips/backndex.html
which is the index to his various "flashes" on custom AIX print backends
A number of these items would be helpful to you. He thought the
following item would be the closest fit, but does recommend that you
review all the items on the backndex.html page.
http://tesch.aix.dfw.ibm.com/printips/shell2c.html
I hope this helps.
S e a r c h - k e y w o r d s:
psf/6000 psf/aix psf aix mvs npf network print facility tcp/ip lprafp
hp hpux hp-ux hp9000 sun ultrix solaris afpsplit acif reprint operator
range pages select custom backend
WWQA: ITEM: RTA000154853 ITEM: RTA000154853
Dated: 12/1999 Category: XPSF6000
This HTML file was generated 2000/11/30~13:34:10
Comments or suggestions?
Contact us