I would suggest you run with more converter tasks. We have ours set at the max allowed (10). I would also question the amount hold and dormancy time you have for the checkpoint for each system. Lizette's question about other datasets on the checkpoint volume is also very important.
Doug On Tue, 4 Jun 2013 22:49:43 +0530, baby eklavya <[email protected]> wrote: >Hello Lizette , > >Thanks for your inputs . $JD commands look normal . Our environment >has a MAS setup with 3 systems .We have more than 15000 Auto Sched >jobs in our daily cycle . As far as i know , there are many jobs >submitted at the same time (approx 20 - 30) ,but this problem doesn't >happen all the time . On some days , 2 or 3 jobs out of the total >(20-30) get into this problem .Workload to JES2 is almost same with >this issue .Primary Checkpoint dataset resides on CF an the secondary >on DASD . Checkpoint is configured in DUPLEX MODE . > >Thanks , >Baby > >On 6/4/13, baby eklavya <[email protected]> wrote: >> Hello Doug , >> >> Thanks for your response . $DPCE(CNVT) indicates 4 PCE's defined and >> created >> >> $HASP653 PCE(CNVT) COUNT=(4,4,0),ACTIVE=0,TRACE=NO >> >> Also , CNVT_ENQ is set to FAIL >> >> On 6/4/13, Lizette Koehler <[email protected]> wrote: >>> You may also wish to look at the $JD commands (HISTORY, STATUS, DETAIL). >>> >>> History of various JES2 elements might help to know when it is CNVT is >>> having a problem. >>> >>> You could also use the SDSF panel (RES???) to do something similar. >>> >>> How many jobs are being handled by JES2 at the time of the issue? >>> How many auto-sched jobs are there? >>> Does this happen at the same time or different times? >>> >>> Is the workload to JES2 the same or different with this issue? >>> >>> Is your checkpoint on DASD or CF? If on DASD are there any other files >>> on >>> the volume with the JES2 checkpoint dataset? >>> How many systems are involved in this environment? 1 , 2 more??? >>> >>> Also, check out the $D PERFDATA command >>> http://www-03.ibm.com/support/techdocs/atsmastr.nsf/585741c64201a45286256ccf >>> 00653ad4/59ebc9c955fc619e85256d8c000d6156/$FILE/perfdataFlashzOSR2.pdf >>> >>> Or tinyurl: http://tinyurl.com/kjkvc6k >>> >>> This command will do: >>> >>> >>> C 1997-2004, IBM Advanced Technical Support Techdocs - Washington Systems >>> Center Version 1/20/2004 >>> http://www.ibm.com/support/Techdocs >>> >>> W9744B - JES2 for OS/390 and z/OS Performance Data >>> Title: JES2 Performance Data Command ($DPERFDATA) >>> JES2 for OS/390 and z/OS Performance Data - Updated January 20, 2004 >>> >>> JES2 provides internal performance statistics which can be displayed with >>> the $D PERFDATA operator command. >>> >>> Disclaimer: >>> This is intended to be used under direction of personnel knowledgeable in >>> interpreting JES2 PERFDATA displays. Development may add/change/delete >>> any >>> part thereof as required to improve its usefulness as necessary, so there >>> is >>> no intent to document the externals in the JES2 product publications at >>> this >>> time. >>> >>> >>> Lizette >>> >>> >>> -----Original Message----- >>> From: IBM Mainframe Discussion List [mailto:[email protected]] On >>> Behalf Of baby eklavya >>> Sent: Tuesday, June 04, 2013 4:34 AM >>> To: [email protected] >>> Subject: JES2 conversion delay >>> >>> Hello , >>> >>> We are running Z/OS 1.11 in our environment and recently had a problem >>> with >>> Auto-sched jobs in Jobtrac . There were a set of auto-sched jobs which >>> comes >>> to JES2 and jobtrac puts a HOLD on it by design (for Auto-sched >>> processing) . Later ,Jobtrac issues a release command to free them for >>> execution . It was found that JES2 conversion took longer and couldn't >>> complete the conversion processing when Jobtrac issued the release >>> command.As a result , the release command had no effect on the job and >>> the >>> job stayed in the JES2 queue waiting for execution . We are not sure why >>> the >>> conversion took longer . Any idea on why this could happen ? >>> >>> Regards, >>> Baby >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, send >>> email >>> to [email protected] with the message: INFO IBM-MAIN >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected] with the message: INFO IBM-MAIN >>> >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
