JES2 WLM INIT's strange behavior
I brought up my sandbox LPAR in my basic sysplex for testing of z/OS 1.7. The other systems are z/OS 1.4. We use WLM managed JES2 initiators where the work is assigned to one of four services classes with varying velocity goals. When running batch jobs on my 1.7 system, jobs for two of my 4 service classes would never begin executing (stayed in the input queue for well over a half hour) unless I changed the service class manually or did $SJ command. I did not have this problem when the sandbox system was in its own monoplex even though the WLM policies are very similar. I also had no problems on the other systems in the sysplex when submitting jobs. This was on a very low utilization day so there was plenty of processor although this LPAR has a very low weight. The goals for the service classes that worked correctly are lower than one of the service classes that didn't work and higher than the other. I remember this behavior from the past but haven't seen it in a long time and I never did try and figure it out since it was on my sandbox. The last time I saw this was when I brought either an upgrade or service into my production system (can’t remember which now) and I re-ipled and the problem went away, then I got busy and didn't track it down. Now that it has happened again in my sandbox I would like to find out what is happening so I don't repeat the production experience. I have searched the archives and IBMLink and either there isn’t anything there or I didn’t search on the correct thing. After finding some things on IBM-MAIN related to PIs I looked at the workload screen in Omegamon II for MVS on the sandbox lpar and the PI for all of the above was listed as n/a (I believe I did get a PI for the classes that worked eventually after running some jobs but not initially). I do not believe I ever saw a PI for the service classes that didn't work even after forcing a few jobs to run. The service class definitions are as follows: Service Class JOBHI - Batch jobs HIGH CPU Critical flag: NO # Duration Imp Goal description 1 4Execution velocity of 40 Service Class JOBLONG - Batch jobs HIGH long running CPU Critical flag: NO # Duration Imp Goal description 1 4Execution velocity of 30 Service Class JOBMED - Batch Jobs Med CPU Critical flag: NO # Duration Imp Goal description 1 4Execution velocity of 20 Service Class JOBLOW - Batch jobs low CPU Critical flag: NO # Duration Imp Goal description 1 5Execution velocity of 10 (JOBLONG and JOBMED jobs would run, JOBHI and JOBLOW jobs would not). I am sure I left out some necessary info and equally sure I include some useless garbage but I don't really even know how to ask my question. I would just like to be prepared in case I see this on my PROD system. I don't like solutions of IPL and it MAY go away. If anyone has seen this or has any ideas what is (or could be) causing this I would appreciate anything I can get. Thank you for your time and assistance, Greg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: JES2 WLM INIT's strange behavior
I had this seemingly exact same problem on my tech LPAR back in November 2006 - z/OS 1.7. The problem went away after an IPL. I suggest opening a PMR with IBM. I queued my PMR to component 5752SC1CX since my problem seemed similar to OA16905. In my case, the dumps taken during the problem didn't point to the problem that OA16905 solved, so I presume I'm still exposed to the issue. I strongly suggest getting to IBM support before you IPL your sandbox again, so they can get doc and perhaps actually fix this once and for all. Brian On Mon, 29 Jan 2007 16:16:17 -0600, Greg Saccomanno wrote: >I brought up my sandbox LPAR in my basic sysplex for testing of z/OS 1.7. >The other systems are z/OS 1.4. We use WLM managed JES2 initiators where >the work is assigned to one of four services classes with varying velocity >goals. When running batch jobs on my 1.7 system, jobs for two of my 4 >service classes would never begin executing (stayed in the input queue for >well over a half hour) unless I changed the service class manually or did >$SJ command. I did not have this problem when the sandbox system was in >its own monoplex even though the WLM policies are very similar. I also >had no problems on the other systems in the sysplex when submitting jobs. >This was on a very low utilization day so there was plenty of processor >although this LPAR has a very low weight. The goals for the service >classes that worked correctly are lower than one of the service classes >that didn't work and higher than the other. > >I remember this behavior from the past but haven't seen it in a long time >and I never did try and figure it out since it was on my sandbox. The >last time I saw this was when I brought either an upgrade or service into >my production system (can’t remember which now) and I re-ipled and the >problem went away, then I got busy and didn't track it down. Now that it >has happened again in my sandbox I would like to find out what is >happening so I don't repeat the production experience. I have searched >the archives and IBMLink and either there isn’t anything there or I didn’t >search on the correct thing. After finding some things on IBM-MAIN >related to PIs I looked at the workload screen in Omegamon II for MVS on >the sandbox lpar and the PI for all of the above was listed as n/a (I >believe I did get a PI for the classes that worked eventually after >running some jobs but not initially). I do not believe I ever saw a PI >for the service classes that didn't work even after forcing a few jobs to >run. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
