Sorry people. I was on vacation and am just catching up on some IBMMain emails
We started having this problem after we upgraded to 1.7 in two of our lpars with a shared spool. We also periodically issue $TOJQ commands to change the DEST for jobs in specific classes. Our performance people noticed an increase of 8-10 mips for JES2 and asked us to inquire. We opened a pmr with IBM. Their initial meaningful response was: I know that some part of command processing was enhanced at 1.7, but I'm not sure if this kind of change would have a relation with what you experienced. Generally speaking, when multiple filters are being used on JES2 command, it is suggested that a limited range is being used as opposed of a wide range, specially if your environment have large queues (many outputs on the queues). If possible, I would like to determine that the cause of the $HASP263/$HASP9207 messages is really caused by these commands. Any possibility to have the command not being issued temporarily, or have it issued at larger interval, and monitor the issuance of the messages based on the changes.... If the above is not a viable option, you could break the command into smaller chunks: $TOJ1-20000... $TOJ20001-40000 ... Each of the above could be issued at different time (not all issued at the same time, or else it will be equivalent to one large command). Even if the command des not actually change any of the output, the processing of the filtering options does require quite a bit of cycles if the queues are large. followed by: I had a talk with JES2 development... What you are experiencing is due to the code change introduced at 1.7 for command processing. At that release, numerous filters were added and although there would be a need of additionnal cycles needed for the enhancements, the overall performance would be negligible on most command... except when using wide range, or JQ, plus adding multiple filters to the command. If the command must need all those filters, then you need to break the command into smaller chunks. First thing you should do is specify a range of couple thousand jobs at a time. We have increased the time between issuing the $TOJQ commands and JES2 cpu utilization has dropped but still not to where it was prior to 1.7 Alan Schwartz Assurant Shared Business Services Lead Systems Programmer Phone: 651-361-4758 Fax: 651-361-5625 Brian Westerman <[EMAIL PROTECTED]> Sent by: IBM Mainframe Discussion List <[email protected]> 12/04/2006 12:48 AM Please respond to IBM Mainframe Discussion List <[email protected]> To [email protected] cc Subject Re: JES2 performance problem - z/OS 1.7 I don't understand, I can't reproduce your problem on my systems here and it's a pretty eclectic group of systems. Can you tell how many jobs are actually purged when you enter the command? I just don't see anything in your parms that would allow your system to hang on to the Checkpoint dataset for 14+ seconds. We must be missing something. There has to be something external (to jes) that's going on to allow the checkpoint to be held for so long with no other exterior indication of a problem. Brian ************************************************************************************** This e-mail message and all attachments transmitted with it may contain legally privileged and/or confidential information intended solely for the use of the addressee(s). If the reader of this message is not the intended recipient, you are hereby notified that any reading, dissemination, distribution, copying, forwarding or other use of this message or its attachments is strictly prohibited. If you have received this message in error, please notify the sender immediately and delete this message and all copies and backups thereof. Thank you. ************************************************************************************** ---------------------------------------------------------------------- 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
