Tested COMPRESS=NO Tested different CKPTPAGE and CKPTLINE.. NO luck.. On Thu, Jun 16, 2011 at 12:21 PM, Cobe Xu <cob...@gmail.com> wrote:
> 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"* > > -- 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
