PSF/AIX: Performance of PostScript/PCL uploaded to PSF/MVS and reblocked
ITEM: RTA000148343
Q:
Topic thread:
Printer Systems (PRINT)
PSF/AIX
Customer has tested a data stream and noted performance problems. What
are we missing?
Customer is taking PostScript output from a UNIX application that's
on a Sun system. It's sent to PSF for AIX on a RS/6000 where
it is transformed into AFPDS. The customer manually sends the file to
MVS (via TCP/IP) where they use our reblock program. Then they use
IEBGENER to put the job on the JES2 spool for printing via PSF to their
3900-001's. (We've tried upload and print, but it's too slow.)
In sending test files they note that the reblock program cannot handle
compressed images (IOCA). Is this true? Is this a bug? Are we missing
something?
Customer also notes that the printer is clutching at about 70
impressions a minute even though the files are IOCA (we think). Is there
a way to output better IOCA from PSF for AIX? I.E., what should we
specify to produce the most efficient output?
Customer also wants to know if they can get a compiled version of the
reblock program. They feel if they have the executable module (instead
of it running in interpretive mode) they would get better performance.
They also do not have the REXX compiler or they'd do it themselves.
Thank you.
A:
It sounds like your performance problems are in the reblocking portion
and then at print time, not at RIP time. If that's not correct, then
please advise. Otherwise, I'll assume the former.
1) Does the 3900-001 support compressed image? (Does it have the AFIG &
DPE feature or was it produced after those features became standard?)
If so, are you sure it's enabled and working? How much memory does
the 3900-001 have?
2) You mentioned IOCA -- for the PostScript and PCL transforms, there
are three types of IOCA, two compressed and one not. Is the customer
specifying an image-type for the transforms other than the default
(which is IO1_G4, compressed IOCA)? The easiest place to check which
values were used for the RIP are in the transform logs. By default,
those logs are called /var/psf/ps2afp/ps2afpd.log and
/var/psf/pcl2afp/pcl2afpd.log. If the 3900-001 supports compressed
image, the best image type to produce is IO1_G4.
Image type can be specified when the transform is invoked on the command
line or through the smit panel, or if not there, then the values in the
configuration files are used (/usr/lpp/psf/ps2afp/ps2afp.cfg and
ps2afpd.cfg for PostScript, or /usr/lpp/psf/pcl2afp/pcl2afp.cfg and
pcl2afpd.cfg for PCL are the default configuration files, but it's also
possible that they may have created custom configuration files.
3) Make sure they're not going off the logical page -- set datack to
unblock or to blkchar for the job. That could be slowing things down
if they're slightly off the logical page. They might try printing with
a formdef with a 0,0 offset (like F100S) as we recommend in the PSF/AIX
Print Submission guide. The recommendation is to use a formdef with
0,0 offset and then, if they need explicit positioning, to use the
-x and -y flags for the ps2afp and pcl2afp rips (either or the command
line, smit panels, or within their transform configuration files).
4) Which reblocking CLIST are they running, old DUVSREB or the newer
AFRREBLK?
a) IOCA problem: The developer is not aware of any problems with IOCA.
After the type of AFP object is determined, the code just reads the
structured field lengths and breaks the records according to that
length. Any valid AFPDS should work.
I just did a test by creating a IO1_G4 image from the PostScript
transform, uploading it to VM (I don't have access to an MVS system
myself), and successfully running AFRREBLK against it.
If the customer can successfully reblock other AFPDS files with
AFRREBLK but is still unable to reblock compressed image files, I
would suggest opening a PMR with the Support Center. If the customer
is unable to reblock any AFPDS files, then I would ensure that they
uploaded the code correctly, as that's where all of the problems to
date have occurred -- by not following the documented upload of the
AFRREBLK code exactly.
b) Compiled version: There are no plans to provide a compiled version
of the reblocker. If you feel this is something that should be added
to the product, you should submit a REQUESTS or NEWREQ for that
function. Alternatively, you may wish to contact PSC Services to see
if this is something they are willing to do under a contract. It's
certainly technically possible. You would lose the ability to add
trace statements into the code for problem determination (as is
currently done when required), but performance of the reblocking
portion of their process should improve.
Thanks for using WWQ&A.
S e a r c h - k e y w o r d s:
psf/6000 psf/aix aix psf mvs afrreblk duvsreb reblock compressed image
uncompressed IO1_G4 ioca performance clutch 3900 AFIG DPE
WWQA: ITEM: RTA000148343 ITEM: RTA000148343
Dated: 01/1999 Category: XPSF6000
This HTML file was generated 99/06/24~12:43:37
Comments or suggestions?
Contact us