Re: PTF uninstall after *PERM application

OOOHHHHHH. that smells guilty!
parsing all 1500 pages or 9999 pages to print the 1501 or 10000 page
would be very disk/cpu consuming (on a small machine).
If i have the time, when i do the reload i WILL test this.
Thanks a lot Chuck!



On Wed, Apr 18, 2012 at 8:27 PM, CRPence <CRPbottle@xxxxxxxxx> wrote:

On 18 Apr 2012 15:15, Roberto José Etcheverry Romero wrote:

The lastest PRINT PTF group was included in the cume, when
downloading the cume from fixcentral i download ALL, cume, hyper,
etc. And i checked with wrkptfgrp that the print ptf grp lvl was the
same as the fixcentral one.

now, if this is a problem solved by a ptf that is not on the normal
groups, i'm lost since i've never understood how to browse the APAR
section...

On Wed, Apr 18, 2012 at 6:19 PM, Charles Wilt wrote:

It appears you can still order v5r3 PTFs...

I'd get the Print PTF group package and apply that...
http://www-912.ibm.com/s_dir/SLINE003.NSF/PTFbyNumber/SF99346

You might also search for any additional PTFs not part of the cume
or the print group...

A cume never contains _ALL_ fixes...

The Print group contains a higher percentage of print related
fixes, but even then I do not believe it's necessarily ALL of
them.

On 18 Apr 2012 at 15:13, Roberto José Etcheverry Romero wrote:

Allegedly, before the ACUM it took 60 seconds for the printers
to restart at the desired page (be that 1501 or 10501) but after
the ACUM it takes up to 40 minutes and CPU stays at 40% during
that time. It may be many things, but the blame fell on the ACUM,
so if it comes to that i'll do whatever it takes to rollback that
acum.

  Not much help to avoid a reload to back-level the code, but, FWiW...
The following is an example of what _could_ be a possible origin:

  The R530 PTF SI31298 is not on the cumulative, but is provided with
the print\spool group, and supersedes the PTF for the following APAR for
which a side effect of the fix provided for that APAR is described
[paying great attention to the last sentence, with the first sentence
for why that effect, of the snippet I included]:

APAR SE10006 Reference #: 86256D09003D4F6F
OSP-PAR *AFPDS SPOOLED FILES WILL NOT DUPLEX WHEN SPECIFYING A PAGE
RANGE TO PRINT
http://www.ibm.com/support/docview.wss?uid=nas2eaca3faee6f35b8886256d09003d4f6f
"...
The printer driver has been changed to parse all the data in the
spooled files up to the starting page, in order to set up the
correct initial conditions for the starting page.  Only the data
beginning with the starting page or the restart page will be
sent to the printer, so the PAGERANGE function will still work. There
may be a noticeable delay before the file begins to print if the
starting page number is high.
"

  After reverting to a prior code level, that PTF could be applied
again, though this time temporarily, to investigate its impact on the
performance of the noted scenario involving CHGSPLFA
RESTART(page-number) to "Restart printing" [which may be the first page
of the specified "Page range to print" (PAGERANGE parameter) per *STRPAGE].

Regards, Chuck
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.