Hi Jack, As previous thread mentioned, COMPRESS could be the cause of some CPU cycles. So we're going to test turn off COMPRESS, will see if JES2 cpu can relief.. Thanks!
On Tue, Jun 14, 2011 at 7:10 AM, Jack Schudel <j...@nersp.cns.ufl.edu>wrote: > Cobe Xu: > > Have you checked to make sure that both compression and compaction are > turned off for the printer? > (Do a $DU,Rn.PRn command and look for CMPCT=NO,COMPRESS=NO.) > By default JES2's RJE printer driver scans for repeated characters to > compress out of the data stream. > That made a lot of sense back in the days of 4800 bit/sec modems, but is > probably just wasted cycles with today's communication speeds. > > If that does not help, you will need to find a way to move the printer > driver out of your main JES2 task. > Are you running multiple MVS images sharing the JES2 spool? > Can you connect the printer to JES2 on one of the images that is not > running CICS as its primary workload? > > If you are constrained to a single MVS image things get more complicated. > One approach would be to run a secondary JES2 subsystem to drive the > printer, and define that JES2 subsystem with a lower WLM importance. > The secondary JES2 could share your main spool, or you could run an NJE > connection between the primary and secondary. > > If CICS really is your most important workload, and you have controls in > place to prevent runaway transactions, some sites have even gone so far as > running their primary JES2 system at a lower importance than CICS. > Personally I don't think that is a wise thing to do, but it really does > depend on the environment. > > Good luck! > > > /jack > > > > > ----- Original Message ----- From: "Cobe Xu" <cob...@gmail.com> > Newsgroups: bit.listserv.ibm-main > > To: <IBM-MAIN@bama.ua.edu> > Sent: Friday, June 10, 2011 12:54 AM > Subject: Re: can limit JES2 RJE work? > > > Hi Greg, >> >> Thanks for the APAR information. >> I checked with JES2 PERFDATA(PCESTAT). We don't have high cpu% for SAPI, >> but >> true for RMT.PRT PCE, over 50%. >> Need to further confirm if our problem match this APAR. >> >> On Fri, Jun 10, 2011 at 1:54 AM, Greg Shirey <wgshi...@benekeith.com> >> wrote: >> >> Could it be APAR OA33407? >>> >>> **************************************************************** >>> * PROBLEM DESCRIPTION: High CPU usage for output device PCEs, * >>> * such as SAPI PCEs, when selecting work * >>> * with user routing. * >>> **************************************************************** >>> * RECOMMENDATION: * >>> **************************************************************** >>> The WSROUT routine in HASPSERV is not distinguishing between a >>> real JOE and an artificial JOE (JOA). So it incorrectly >>> determines for a JOA that it cannot utilize the user routing >>> information to do work selection, so significantly more devices >>> are posted than should be. When the device attempts to do work >>> selection it cannot find JOEs that match. This incorrect >>> processing results in excessive CPU usage. >>> This problem affects the following output devices when they >>> select work with user routing: printers, punches, SYSOUT >>> transmitters, and SYSOUT API (SAPI). >>> >>> Greg Shirey >>> Ben E. Keith Company >>> >>> >>> >>> >>> ----- Original Message ----- >>> From: "Cobe Xu" <cob...@gmail.com> >>> To: IBM-MAIN@bama.ua.edu >>> >>> Recently, we have a problem when sending large amount spool files (about >>> 2.5 >>> million lines) to RJE printer, as the work caused JES2 consumes lots of >>> CPU, >>> therefore impacted >>> the CICS online performance. >>> We consider to limit JES2 address space CPU, using WLM resource group, >>> but >>> this will suppress other JES2 process as well. So, any idea to limit RJE >>> work only? >>> Thanks a lot! >>> >> >> >> >> -- >> Cobe Xu >> >> Best Regards >> ----------------------------------------------------------- >> z/OS Performance & Capacity Analyst >> z/OS System Programmer >> Email: cob...@gmail.com >> ----------------------------------------------------------- >> > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO > Search the archives at http://bama.ua.edu/archives/ibm-main.html > -- Cobe Xu Best Regards ----------------------------------------------------------- z/OS Performance & Capacity Analyst z/OS System Programmer Email: cob...@gmail.com ----------------------------------------------------------- *"Impart fishing is much better than just donate fishes"* ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
