Psegs with PSF for AIX
ITEM: RTA000159925
Q:
Topic thread:
Printer Systems (PRINT - NA/ATS)
PSF/AIX
I have a costumer with PSF for AIX v. 2.1 and an IP4000 ID1/ID2.
He is sendind a data with Structured Fields calling images ( Psegs )
dynamically. There are 7 psegs. He said that the performance decreased
70% using this solution. When he calls the psegs in the pagedef, the
perform is good, but he really needs to call the images dynamically.
I asked him to declare in his pagedef the psegs that he'll use with the
Segment command, but this not solved the problem.
If you need more information, please ask me¢
Thank in advance¢
A:
Your advice was excellent. This should have fixed the problem.
Maybe the customer is not doing what you suggested, or not doing it
correctly. Have you verified that they have created a Page Definition
that maps all 7 page segments, and that they are invoking this pagedef
for the job? Does the pagedef have multiple page formats, and if
so, have they specified the page segments for all the pageformats
which will be used for this job?
Also be sure they are not getting errors when they are printing.
Perhaps when they call in the page segments dynamically, they are
placing some off the page and causing positioning errors.
So be sure they are printing with DATACK UNBLOCK so you can see the
errors.
Q:
I talked with the customer and he said that all psegs were defined in
all page formats inside the Page Definition. On monday I'm going there
to do some tests, looking for errors and to run a trace. I'll use
DATACK UNBLOCK to see some error regarding to off the page, but he said
to me that all images are being positioned good in the printed pages.
If you have some Tips/ideas to give me, please send me. It'll be my
first trace running for PSF/6000, so could be helpful some tips or steps
that I have to follow. I'll check for your tips on the weekend if you
have someone.
Thanks and please, wait my feedback¢
Q:
They are defining the page segments correctly in all page formats.
I did a trace and get messages in the error.log and trace.log files. I
will show you some pieces of these files:
error.log:
08/30/99 17:44:09 0420-237: Starting the Error Log for printer
IP4000D.
08/30/99 17:44:09 0420-885: PSF is establishing communications
with IP4000D.
ain3ddii.c 475
08/30/99
17:44:15 0420-252: The sense bytes received from the printer are
X'01000D000002B00200000000000000000000000000000000'.
08/30/99 17:45:50
0420-252: The sense bytes received from the printer are
X'08C10100DE01000100000000D62D050200000000FFFF0001'.
08/30/99 17:45:50 0420-249: PSF received IPDS exception X'08C1..00',
action code
X'01' from the printer.
Job Name=/var/psf/tmp/rqnsEa Job ID=00760 Node
ID=ibmserve User ID=root
08/30/99 17:46:27
0420-252: The sense bytes received from the printer are
X'08C10100DE01000100010000D63E000100000000FFFF0002'.
08/30/99 17:46:27 0420-252: The sense bytes received from the printer
are
X'08C10100DE01000100000000D62D060200000000FFFF0002'.
08/30/99 17:46:30
0420-130: ERROR: The name of the resource in error is O1VAZIO.
Job Name=/var/psf/tmp/rqnsEa Job ID=00760 Node
ID=ibmserve User ID=root
08/30/99 17:46:30
0420-249: PSF received IPDS exception X'08C1..00', action code
X'01' from the printer.
Job Name=/var/psf/tmp/rqnsEa Job ID=00760 Node
ID=ibmserve User ID=root
08/30/99 17:46:30 0420-249: PSF received
IPDS exception X'08C1..00', action code
X'01' from the printer.
Job
Name=/var/psf/tmp/rqnsEa Job ID=00760 Node
ID=ibmserve User ID=root
The trace.log:
....SFIO >SFIO_ftell stream_p=305e22dc
....SFIO File I/O stream descriptor:
eyecatcher=SFIOSTRM type_flag=2 stream_p=0
stream_name=/var/usrlib/S1FINEND.PSEG38PP
file_class=2 stream_size=62502 _flag=0
rba=24824 b_cur_p=3058414c b_avail=7944
CURRENT Buffer: b_p=30584054 b_rba=24576 b_max_size=8192
b_actual_size=8192 b_pool=30580008
NEXT Buffer: b_p=3058605c b_rba=32768 b_max_size=8192
b_actual_size=8192 b_pool=30580008
handle=22 async_flag=1 async_sem=0
async_b_to_read=8192 async_b_read=8192 async_rc=0
....SFIO sfi_buf_num_bytes_left_over=0
so sf_offset=16624
....CGET CGET_RETURN_STRUCT:
sf_offset=16624
sf_code=EEFB IPD
sf_seq_num=0
sf_info_p=2000a4d8
sf_data_len=8192
sf_data_p=30605fdc
....CGET structured field data:
....CGET .30605fdc FE921FFC35AAAAA4AAAAAAAAAAAAAAAA
....CGET .30605fec AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
....CGET .30605ffc AAAABF11111111111111111111111111
....CGET .3060600c 11111111111111111111111111111711
....CGET .3060601c 0D0A090542A290D0A4290870C2A11114
....CGET .3060602c 84444444444444444444444444444444
....CGET .3060603c 44444444
....CGET status=0
....COBJ SF read: IPD (X'D3EEFB')
offset=16624
sequence num=0
length=8192
data_p=30605fdc
....COBJ cell matches SF ID: X'EEFB'
....COC9 >COCA_ipd_s
....COC9 sf_len=8192
sf_p=30605fdc
f_p=305e22dc
offset=16624
seq_num=0
fstack_p=305e28bc
status_p=2002f694
About the O1vazio specified in the error.log file, I did a test without
the O1vazio overlay but the performance remained the same and the
messages sent to the error.log file remained the same too ( 0420-249:
PSF received IPDS exception X'08C1..00', action code
X'01' from the printer.
).
I got messages in the trace2.log , so if you need it , please ask me.
I'll look at the data with structured field to find some mistake. If you
have some tips or information for me, please send me.
Q:
Hi¢ After several days... I'd like to continue this PMR. We've tested a
lot , increased RISC and IP4000 memory , created PSEGS again using AFP
Driver, etc... But the performance is still bad. We was always getting
the error.log message: IPDS exception X'08C1..00', action code X'01'
from the printer, that means a printing off the page size.
We was positioning two PSEGS size A5 (one besides the other) in an A4
pagesize. But now, we fixed it. We are positioning both in origin 0 0
(structured field). Thus, the error log message above has gone off.
Positioning both PSEGS in the origin doesn't solve our problem, because
we have to place both besides. But for testing time, it's ok¢ Althougth
we fixed the position off of page, we still have bad performance.
We did the same test in an IP20 ( the same data , PSEGS,etc ) and the
performance was good.
A:
The previous responder is out of the office all week at
the US XPLOR Conference. She should be back in the office on Monday,
8 November.
Is the performance delay only when the page segments are first loaded in
a particular job? If so, PSF/AIX does allow you to keep segments
in the printer memory between jobs. The default setting is to keep
no jobs in printer memory between jobs. To change the setting, go to
Show / Change Characteristics of a PSF for AIX Printer, select Tuning
Options and select the IP4000. (The smit fastpath is:
smit psf_prt_sel_tuning_options). On the Tuning Options panel, you can
change the value for the "MAXIMUM number of SEGMENTS to keep between
jobs" to 7 and press ENTER or DO. I recommend bouncing the instance
of PSF/AIX for this print queue (psfctl -dtu psfqname or psfctl -dku
psfqname); the ain processes running for this printer must all stop
and be restarted so the printer profile is reread after you make the
changes. Then try printing the job again and see if the performance
after the page segments are initially loaded improves.
There is also an option under Show / Change for "Error Handling Options"
that determines if PSF/AIX will continue or stop a job when an image
or graphic error is encountered. The default is "no", which means to
continue printing the job even if errors occur, with the errors then
printed out at the end of the job. You can change it to "yes" to have
the job stopped if there are any errors in the image or graphics
objects. If you change this value, again you should stop/restart the
PSF/AIX queue so the printer profile is reread.
If these suggestions don't help, I would suggest that you open a PMR
with Level 2 Defect Support so they can assist you with any traces
that might help determine the problem.
A:
Also ensure that your customer has current PSF/AIX maintenance on.
Thank you for using ViewBlue/Techline.
Q:
A:
WWQA: ITEM: RTA000159925 ITEM: RTA000159925
Dated: 11/1999 Category: XPSF6000
This HTML file was generated 2000/11/30~13:34:12
Comments or suggestions?
Contact us