PSF/AIX Postscript RIP performance problem
ITEM: RTA000148041
Q:
Topic thread:
Printer Systems (PRINT)
PSF/AIX
Customer has an 11,000 page Payroll application on UNIX that was
taking close to four hours to RIP on PSF/AIX before uploading to
PSF/MVS to print on a 3835. He found the four hours unacceptable.
(IBM Link sent him PTF U450109 which cut the RIP down to two hours but
the printing was garbled. IBM Link said he is the only one having
problems with this fix so they're sending him other PTFs to get the
RIP working properly.) But he is not satisfied with the two hour RIP
either. Since this equates to over 90 pages/minute, maybe this is the
best he's going to get given that each page has a check and receipt
with logo, signature, and multiple fonts. When he got the performance
boost by applying the PTF he did NOT change anything on the config-
uration. His RS/6000 is Model 7025 F50 and he is using only one CPU
with PSF/AIX. RS/6000 has 256 MB memory, and 512 MB paging space
and there are NO OTHER APPLICATIONS running concurrently. The level
of AIX is 4.2.1 and the level of PSF/AIX is 2.1.0. The only PTFs for
for PSF/AIX other than U450109, (which has been removed because of
the problem it caused,) are U447344, (which deals with PCL,) and
U453368, (don't know what it fixes.)
He is submitting jobs from the HP UNIX box using the LPR command that
was created with IBM source and recompiled on HP to give him all the AFP
parameters. (This LPR command is embedded in a batch routine as part of
submitting the Payroll program so the users don't personally submit the
print job).
He believes the 3835 has DPE and AFIG because it originally was
"clutching" and they had to upgrade it to get it to run at rated speed.
The RS/6000 is on an Ethernet LAN and he doesn't think there is a
traffic problem on it. He also didn't know how to track the different
job segments and time them like RIP vs Upload.
They may be receptive to getting another RS/6000 to share the RIP
cycles -- he has already divided the job into multiple parts so
that would shrink the total time also.
There is a separate issue: when the jobs are submitted with SMIT
and he goes into Job Status, they don't show up. How can he monitor
them?
Thanks.
A:
I'll take a look at your specific questions above, but in the meantime,
please take a look at libraried ViewBlue item RTA000145160. It describes
some of the same concerns this customer has. There may be some things
we can suggest that will allow the job to begin uploading before the
entire rip is done (segmenting) and may eliminate some of the total
elapsed time for the process. It would be worthwhile to review if
NFS-mounting the data would help cut down on the total elapsed time
as well (thus eliminating the transfer from the remote system to the
RS/6000).
Can you get the customer's sample job so that we can test it on
another system to see if hardware configuration changes might improve
the rip time?
Leaving open while you review the referenced item and I check out your
questions.
A:
After reviewing your customer's question in more detail, I have the
following comments.
1) I received the fax of the settings in the various configuration files
and the one that jumps out at me is that ps_max_memory is currently
set way too high. Your customer has it set to 61440K. Development
recommends no more than 12000K, with 6000K (the default) or 8000K
being adequate for most cases. With the value set excessively high,
there is a lot of overhead taking place related to memory management,
and that can negatively impact performance. 61MB is excessive unless
you're rasterizing 600 dpi pages that were 30 inches long or
something along those lines. The developer recommends setting the
values for both ps_max_memory and pcl_max_memory to probably 8000K.
The pcl interpreter uses the same rasterizer code, and therefore
pcl_max_memory should be set to the same value as ps_max_memory.
These parameters appear in the ps2afpd.cfg, ps2afp.cfg, and your
customer's customized paycheck.cfg files in /usr/lpp/psf/ps2afp and
in pcl2afpd.cfg and pcl2afp.cfg in /usr/lpp/psf/pcl2afp.
2) The problem your customer had relating to application of U450109:
Your customer initially installed U450109 to get the fix for APAR
IX55200, "PostScript Transform Speed Too Slow" but encountered other
problems as a result of applying that PTF. Let me explain why and
suggest an interim alternative.
PTF U450109 changed the way the PostScript image is handled and
caused the printer to shift the image too far on both AFCCU and CCU
printers; it has already been fixed in AFCCU microcode, and a fix
is currently being tested for CCU printers like the 3835 or 3900-001.
If your customer is seeing shifted output (and I can't really tell
from their PMR), this may be why. Level 2 has left a message for
customer to verify the printer model and its microcode level. I sent
you a copy of the PMR offline.
Until the CCU microcode is fixed, we can probably arrange to get the
next earlier PTF, U444135, which does contain the fix for APAR
IX55200 and would get them the performance improvement. They'd be
missing one APAR in U450109, but that APAR doesn't appear relevant
to your customer's configuration. Let me know if you want me to
pursue this, or we can work it through the PMR.
3) The current (as of 2/3/98) list of PTFs for PSF/AIX is:
UQ11744 - psf.acif
U454050 - psf.base
U453812 - psf.man
UQ12321 - psf.ppfa
U447344 - psf.pcl
U450109 - psf.ps
U454175 - psf.sap
4) PERFORMANCE: The customer is running on just about the fastest
RS/6000 available today and appears to have plenty of memory. We
could check to see where the bottleneck might be (CPU, I/O, etc.),
but if the bottleneck is CPU, then there's not a significant upgrade
path. A new 332MHz chip upgrade has been announced for the F50, but
I can't predict how much relief that would provide.
What I can say is that the way the customer is currently configured
leads to a serialized process, and I can make recommendations that
would allow some parallel processing to take place. This could have
the effect of reducing the total elapsed time for the print job even
though it wouldn't impact the actual RIP time for the PostScript.
My understanding of the customer's current configuration is this:
a) Customer's payroll application generates a file on an HP-UX
system and then issues the lprafp (LPR -A) command against that
file.
b) The lprafp command sends the file to the lpd daemon running on the
RS/6000. The entire data file and the control file must be
completely received on the RS/6000 before the job is spooled by
the AIX qdaemon and passed to the PSF/AIX AFP Upload queue.
c) The ps2afp PostScript transform are invoked, and the entire job
must be RIP'ed into AFPDS image in its entirety before uploading
begins.
d) The entire AFPDS file must be uploaded to MVS (to a SYSOUT data
set) before it is reblocked and spooled to JES and PSF/MVS for
printing.
As you can see, in this configuration each step must complete before
the next step can begin. There are some modifications that can be
made to this configuration to allow some parallel processing, as
follows:
a) Rather than the application writing to a file on the fixed disk
on the HP-UX system, perhaps they could write to an NFS-mounted
disk that actually resides on the RS/6000. This would eliminate
the time it takes to spool the file from the HP-UX system to the
RS/6000.
b) The customer's application could use the "rsh psfin" command to
submit the job to the PSF/AIX Input Manager. Submitting the job
through PSF/AIX's Input Manager allows segmenting. By this, I
mean that the PostScript transform will begin the RIP. However,
rather than waiting for the entire 11,000 page job to be
transformed, segmenting means that as soon as there is an AFPDS
segment of a user-customizable size (default=100K), it will begin
to be Uploaded to MVS. Thus you are RIP'ing and Uploading in
parallel.
If they choose not to implement the NFS-mount described in (a) or
to use the "rsh psfin" command and do continue to use lprafp in
their application, they can still get their job into Input Manager
through the use of double-queuing. I'll include a Fax from the
AIX Support Center below that describes how to set this up.
c) The entire AFPDS file must still be uploaded to MVS (to a SYSOUT
data set) before it is reblocked and spooled to JES and PSF/MVS
for printing. However, the total elapsed time from the time the
payroll application issues the print command to the time the job
prints on the PSF/MVS-attached 3835 should be reduced because of
the segmenting in Step (b).
Another instance in which we have been able to improve performance
for some customers has to do with products or applications that
don't produce efficient or "clean" PostScript. In those cases (and I
don't know if your customer's data falls into this category), some
customers have been able to improve the transform time by first
running their PostScript source through Adobe Distiller to clean it
up. Something to consider, but no guarantee.
Another possibility: the default interpreter with PSF/AIX V2 is an
interpreter that supports PostScript Level 2. If your customer's
application produces only PostScript Level 1 and does not include
any operators specific to Level 2, then they would likely get
better performance by running the Level 1 interpreter we still ship
with PSF/AIX V2. I can give you information on how to do that if
it's appropriate for your customer or if they want to try it.
One more possibility in this area: the PostScript transform that
ships with InfoPrint Manager V2 is a true Adobe RIP, whereas the
transform in PSF/AIX is not. The Adobe RIP has shown itself to
be faster than its predecessor, particularly for L2 data, often
twice as fast. Although InfoPrint Manager doesn't yet support
Upload, that is a known requirement, and perhaps you can special
bid the Adobe transform now with the understanding that your customer
will upgrade from PSF/AIX to InfoPrint Manager as soon as the Upload
function is included.
5) Multiple transforms: Your customer has expressed a willingness to
split the job into smaller jobs and run multiple transforms at the
same time. Since he has an SMP F50, that is practical since he
has multiple CPUs. However I would want to consider: if he is using
prenumbered checks on the 3835, how is he going to synchronize this?
Would he want to rip multiple jobs then recombine them before the
Upload? That could be done, but I'd recommend an evaluation by
someone in our Application Solutions Services group.
If your customer is interested in configuring multiple ps2afpd
daemons, refer him to PSF/AIX Print Administration (S644-3817-03),
page 290. Or there's also a ViewBlue item out there with information
(RTA000037105).
If the customer runs multiple transforms, he may also wish to run
multiple AFP Upload queues. This can certainly be done; the
network protocol (TCP/IP or SNA) will determine how it's done.
I'd refer you to the AFP Upload guide for the customer's protocol
(S544-5423 for TCP/IP, S544-5422 for SNA).
6) You had asked how to track the time spent on each of the steps
in their current process. The start and stop times of the PostScript
transform will be noted in the /var/psf/ps2afp/ps2afpd.log. To
see how much time the Upload process takes, there's not a single
log where this information is written, unfortunately. The PSF/AIX
accounting exits can't be used because they are not invoked for
AFP Upload. The best I can suggest for an occasional check would
be to ensure that the system clocks between the MVS host and the
RS/6000 are fairly closely synchonized. Then you could compare the
stop time of the ps2afp transform on the RS/6000 with the start time
of the print job on the MVS system. Note that this is only valid
if the customer continues to use their current serialized process.
If they start using Input Manager, this procedure wouldn't work.
7) You had asked for the best way to capture a sample PostScript for
testing. One way is that you could capture the file that the
application creates on the HP-UX box before it gets erased.
Another way would be to disable the PSF/AIX queue on the RS/6000
(psfctl -dt queuename) and run the application on the HP system.
When the job is spooled to the RS/6000, the PostScript file will
be in /var/spool/lpd with a system-generated name (the format of
which depends on the level of AIX). If you cat (or more or pg)
the file, you can verify that it's the one you want to make a
copy of.
8) On your last question, you say that when jobs are submitted with
smit, he is unable to see the items when checking Job Status.
a) What smit panel is he using to submit the job? Is the fastpath
command "smit qprt" or "smit psf"?
b) And what smit panel is he using to display job status? Is the
fastpath command "smit jobs" or "smit psf_com_status"?
In both (a) and (b), the first smit fastpath I listed is an AIX
smit command, and the second is a PSF-specific smit command.
If you use the regular smit AIX printing panel to submit a job and
then try to see the job status through the smit PSF panels, you
will not see the jobs that were submitted with AIX print commands or
the AIX "smit qprt" panel. The PSF job status panel can only track
jobs that were submitted through the Input Manager because jobs
submitted in this manner do not use the AIX spool. Jobs can be
submitted to Input Manager through the "smit psf" panel or through
the psfin command (either from the command line or from a shell
script, like the MVS Download shell script).
I hope this information helps you and your customer. Please reopen if
you want to pursue getting the next-older PTF for the PostScript
transform. Thanks for using ViewBlue.
************************************************************************
04/23/96
PSF for AIX v2.1 and Double/Triple Queueing (for Special Situations)
SPECIAL NOTICES
Information in this document is correct to the best of our
knowledge at the time of this writing. Please send feedback
by fax to "AIXServ Information" at (512) 823-4009.
Please use this information with care. IBM will not be
responsible for damages of any kind resulting from its use.
The use of this information is the sole responsibility of
the customer and depends on the customer's ability to eval-
uate and integrate this information into the customer's
operational environment.
ABOUT THIS DOCUMENT
The information contained herein has ONLY been tested using
PSF for AIX v2.1, running on AIX v4.1.4. Slight variations may
be needed for any other product level or operating system level.
------------------------------------------------------------------------
FAX: rev 1.0.2
REV DATE: 4/25/97
GROUP: PSF
COMPONENT: QUEUEING SUBSYSTEM
TITLE: DOUBLE/TRIPLE QUEUEING WITH PSF AND AIX
There are times when a user will want to accomplish a level of complex
routing or printing with special default parameters. At those times, i
may appear that there are several methods of accomplishing the same goal
but in order to make the task simple and easy to support, AIX
SupportLine is providing this fax to show guidelines & recommendations
for certain scenarios. Although they may not exactly match what you are
looking to accomplish, the information provided should be enough to see
how to get started.
This fax is SPECIFIC to the Print Services Facility (PSF/AIX) software.
INDEX OF SCENARIOS:
-------------------
Scenario #1: Printing from a remote system, with the original document
in PostScript format, to a PCL-only printer.
Scenario #2: Printing from a remote system, using the Input Manager on
the PSF/AIX system in order to place the job on the PSF
spool, thereby allowing use of the the PSF SMIT panels.
SCENARIO #1:
------------
> Description:
Source Data Type: PostScript
Source System: Solaris
Target Printer: HP LaserJet 2
Printer Datastream: HP/PCL4
Target System: AIX 4.1.x
> Actions Required:
1_ The data must be converted from PostScript into PCL.
2_ The print job must go from a SUN/Solaris system to an IBM/AIX
system, via TCP/IP's LPD protocol.
> Analysis:
1_ To convert the data from PostScript into PCL using PSF, first
the data must go from PostScript into AFPDS, and then from
AFPDS into PCL. This results in two separate transform
processes. One is performed by the "ps2afp" program, which
which can be invoked if the "datatype=ps", and the other is
handled internally to PSF if the HP LaserJet is being driven
by PSF.
2_ Since the TCP/IP LPD protocol is generic, and does not support
PSF options, there are two possible solutions to getting the
print job over with the right attributes: compiling and using
the 'lprafp' utility provided with PSF/AIX on the SUN system,
using triple queueing on the AIX system. (This scenario will
deal with the queueing options.)
> Solution (Perform these steps in the order provided):
A_ Define an AIX printer queue for the HP LaserJet. The process
for this can vary widely based on the connection type. Please
follow the procedure you would normally use for defining AIX
printers and printer queues to your system.
In our example, we are using "smit mkpq", selecting hpJetDirect
and end up with:
------------------------------------------------------------------------
Name of new PRINT QUEUE to add (hp2)
------------------------------------------------------------------------
B_ Define a PSF printer for the HP LaserJet. (The SMIT fastpath
for this is "smit psf_add_parallel".) You will be prompted
to select the type of datastream (PCL4, PCL5, or PCL5C), then
you will need to add the 'Printer NAME', and modify the
'COMMAND to execute for printer output' to use the name of
the AIX-defined printer created in Step A. Remember that the
PSF printer name should be 7 characters or less if you intend
to use "lpstat" for checking the queues.
In our example:
------------------------------------------------------------------------
* Data stream type PCL4
* Printer NAME (hp2psf)
* COMMAND to execute for printer output (qprt -P hp2 -dp -Zą -o -fv
Description (PSF Queue for LaserJet 2)
------------------------------------------------------------------------
C_ Define an AIX printer queue specifically to call the PSF print
queue with special PSF parameters. In this case, we want to
create a queue which will accept only PostScript as input, and
let PSF worry about getting it to the printer as PCL. (The
SMIT fastpath for this is "smit mkpq".) Select 'other' as
attachment type (allowing for a 'User Defined Backend').
In our example:
------------------------------------------------------------------------
* Name of QUEUE to add (pshp2)
* Name of QUEUE DEVICE to add (psf)
* BACKEND PROGRAM pathname (usr/lpp/psf/bin/ainbe hp2psf datat=ps f=F1
------------------------------------------------------------------------
All other fields on the 'Add a Print Queue' panel may remain
unchanged.
D_ Define a remote print queue on the Solaris system which names
your AIX system as the 'hostname of the remote server' and the
queue "pshp2" as the 'name of queue on remote server'.
In our example, the Solaris remote queue is called "SUNhp2".
> Usage / Process:
Now there are a total of four print queues created. One is on the Sun
system, and the other three are on the AIX system ("triple queueing")
1_ The PostScript job is queued to "SUNhp2" by means of a print
command or via some application.
2_ The Solaris system transfers the file to the AIX system via TCP/IP
indicating that the job is destined for queue "pshp2".
3_ The AIX system accepts the file via LPD & queues it to "pshp2".
4_ The qdaemon invokes the 'ainbe' program (PSF backend), specifying
that the job goes to the printer called "hp2psf", with an
option of "datatype=ps".
5_ The backend program calls the necessary transform program to
convert the data from PostScript into AFPDS.
6_ The backend program checks to see the type of printer "hp2psf" is
and determines that it is not an IPDS printer, but a PCL printer
instead. As a result, it calls an internal process to convert
the AFPDS data into PCL.
7_ The backend program then uses the "Command to execute..."
(specified in the definition as 'qprt -P hp2 ...') to queue the
job to the "hp2" queue.
8_ The qdaemon prints the job queued to "hp2" on the LaserJet printer
SCENARIO #2:
------------
> Description:
Source Data Type: S/370 line data (1403)
Source System: MVS/ESA, JES2/ESA, TCP/IP for MVS
Target Printer: IBM 3130 printer
Printer Datastream: IPDS
Target System: AIX 4.1.x
> Actions Required:
1_ The data must be converted from line data into IPDS.
2_ The print job must go from the MVS system to the AIX system,
via TCP/IP's LPD protocol.
3_ The data must be enqueued on the AIX system with the "psfin"
command in order to use PSF/AIX's Input Manager. This will
allow use of the Production Print Operator Interface for
these jobs.
> Analysis:
1_ To convert the data from line data into IPDS using PSF, the
data must be processed by ACIF. This can happen automatically
if PSF is told that the input datastream is line data (i.e.
datatype=line). Once ACIF processes the line data into AFPDS
PSF will create the IPDS and send the data to the printer.
2_ Since the TCP/IP LPD protocol is generic, and does not support
PSF options, there are two possible solutions to getting the
print job over with the right attributes: using the MVS Down
facility (which is a feature of PSF/MVS), or using double
queueing on the AIX system. (This scenario will deal with
the queueing options.)
> Solution (Perform these steps in the order provided):
A_ Define a PSF printer for the IBM 3130 printer. (The SMIT
fastpath for this is "smit psf_add_prt_tcpip".) You will be
asked for the 'Printer NAME' and 'Internet Address' of
the printer, as well as several other options, for which you
may take over the defaults. Remember that the PSF printer name
should be seven (7) characters or less if you intend to use
"lpstat" for checking the printer queues.
In our example:
------------------------------------------------------------------------
* Data stream type IPDS
* Printer NAME (psf3130)
* Internet Address (100.1.1.2)
* PORT number (5001)
* Number of QUEUE DEVICES (4)
* Connection TIMEOUT (seconds) (30)
Description (PSF Queue for IBM 3130)
------------------------------------------------------------------------
B_ Create a shell script which will call the "psfin" command using
STDIN (standard input) as the input type. If you do not have
a user directory for special code, we recommend you create
one separate from your software libraries. You will also need
to make the file executable. Here are the commands needed to
make a user library, edit the file, and make it executable
(respectively):
# mkdir /usr/lpp/psf/userlib
# vi /usr/lpp/psf/userlib/rmtpsfin
# chmod 755 /usr/lpp/psf/userlib/rmtpsfin
The source for the file "rmtpsfin" follows. Note that the
parameter passed to the shell script which contains the
temporary filename of the AIX spool file is the SECOND
parameter, not the first (hence the $2 in the source):
NOTE: If you are doing the double queue locally and not
from a remote system, then change the $2 to a $1:
------------------------------------------------------------------------
#ą/usr/bin/ksh
/bin/cat $2 | /usr/lpp/psf/bin/psfin -j /usr/lpp/psf/userlib/rmtpsfin \
-i stdin -q psf3130 -s
------------------------------------------------------------------------
| NOTE: If you are doing the double queue locally and not
| from a remote system, then change the $2 to a $1.
C_ Now you need to create the Job Script referenced in the shell
script by the '-j' parameter. By convention, we will name it
'rmtpsfin.js':
# vi /usr/lpp/psf/userlib/rmtpsfin.js
The source for the file 'rmtpsfin.js' follows. You will need
to specify parameters which are unique to your data and
installation. Refer to the Print Submission manual for
further details on creating a Job Script for PSF:
------------------------------------------------------------------------
JsFileType=line
a_FileFormat=stream
a_Pagedef=P1V06483
a_Chars=GT15
a_Imageout=IOCA
a_Cc=yes
a_Cctype=a
a_Trc=no
oa_Formdef=F1A10110
o_Copies=1
o_Bin=1
o_Duplex=no
o_MsgCount=16
o_DataCk=unblock
o_JobName=RMT_USER
o_Distribution=room51e
e_PrintQueue=psf3130
e_Notify=-C
e_Priority=10
------------------------------------------------------------------------
NOTE: If you are currently using a parameter file (parmdd) for
ACIF processing, you will need to convert the parameters into
Job Script attributes (above) since the "psfin" command will
automatically call ACIF using the Job Script attributes that
apply.
D_ Define an AIX printer queue specifically to use the PSF print
command "psfin". Since the "psfin" command CANNOT be called
as an AIX backend program, the korn shell script created in
Step 'B' will be used instead. (The SMIT fastpath to create
the queue is "smit mkpq".) Select 'other' as the attachment
type (allowing for a 'User Defined Backend').
NOTE that MVS is not case-sensitive, but AIX isą As a result
the QUEUE name you select MUST be in upper-case in order for
AIX to match the file to the proper queue, because the "LPR"
command on MVS will send the queue name down in upper-case
whether you specified it that way or not.
In our example:
------------------------------------------------------------------------
* Name of QUEUE to add (MVS2AIX)
* Name of QUEUE DEVICE to add (psf)
* BACKEND PROGRAM pathname (usr/lpp/psf/userlib/rmtpsfin)
------------------------------------------------------------------------
All other fields on the 'Add a Print Queue' panel may remain
unchanged.
E_ .Optional. You may want to set your default printer on the MVS
system so that your LPR command will default to the special
printer queue you've created. Replace 'psfaix_hostname' below
with the hostname of your AIX system:
TSO LPRSET MVS2AIX@psfaix_hostname
> Usage / Process:
Now there are two print queues created. Both of them are on the AIX
system, where one will enqueue data to the other ("double queueing").
1_ The line data job is queued to the AIX spool by means of the
TCP/IP command "LPR" on the MVS system. The job is destined
for the queue called 'MVS2AIX' on the remote AIX system.
2_ The AIX system accepts the file via LPD and queues the job to
'MVS2AIX'.
3_ The qdaemon invokes the program specified as the 'MVS2AIX' backend
(our shell script "rmtpsfin") and passes certain parameters to the
script which allow it to find the input data on the AIX spool.
4_ The backend script executes the commands necessary to enqueue the
data on the PSF spool using "psfin" (or Input Manager). The PSF
printer queue specified on the "psfin" command is "psf3130" (and
this overrides what is specified in the Job Script).
5_ During the "psfin" processing, ACIF is called to convert the line
data into AFPDS using the attributes specified in the Job Script.
The resulting output is then queued to "psf3130".
6_ The qdaemon invokes the 'ainbe' program (PSF backend) for psf3130.
This program checks to see what type of printer "psf3130" is,
and determines that it is an IPDS printer. As a result, it calls
an internal process which converts the AFPDS data into IPDS, and
prints the data on the printer.
Since this data was processed using the Input Manager ("psfin"), the
actual job enqueued to the printer resides on the PSF spool, not the AIX
spool. As a result, the SMIT panels that come with PSF/AIX may be used
to manipulate the jobs. Examples of these panels include "Show Job
Status" and "Work with Jobs (such as Cancel, Interrupt, Restart)".
Additionally, operators have the ability of moving the jobs from one
PSF printer queue to another.
READER'S COMMENTS
Please fax this form to (512) 823-5972, attention "AIXServ Informa-
tion".
Use this form to tell us what you think about this document. If you
have found errors in it, or if you want to express your opinion about
it (such as organization, subject matter, appearance) or make sug-
gestions for improvement, this is the form to use.
If you need technical assistance, contact your local branch office,
point of sale, or 1-800-CALL-AIX (for information about support offer-
ings). These services may be billable. Faxes on a variety of sub-
jects may be ordered free of charge from 1-800-IBM-4FAX (415-855-4329
outside U.S., from fax machine phone).
When you send comments to IBM, you grant IBM a nonexclusive right to
use or distribute your comments in any way it believes appropriate
without incurring any obligation to you.
NOTE: If you have a problem report or item number, supplying that
number may help us determine why a procedure did or did not work in
your specific situation.
Problem Report or Item #: ___________
Branch Office or Customer #: ___________
Be sure to print your name and fax number below if you would like a
reply:
Name: Fax Number:
______________________________________________________________________
______________________________________________________________________
______________________________________________________________________
END OF DOCUMENT (psf.howto.dblq.zap 4FAX# n/a)
*********************************************************************
S e a r c h - k e y w o r d s:
psf psf/6000 psf/aix postscript transform performance ps2afp ps2afpd
ps_max_memory pcl2afp pcl2afpd U450109 clutch Upload mvs psf/mvs 3835
3900-001 3900
WWQA: ITEM: RTA000148041 ITEM: RTA000148041
Dated: 11/1998 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:37
Comments or suggestions?
Contact us