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