Re: Real Storage Occupancy
It's not the possible problem of the real storage occupancy (conceivably in the future driving paging or some other problem) that should be the reason for investigation. Instead, it should be whether there is an application problem (such as a virtual storage leak). If you feel comfortable that the application is doing its job properly and happens to need additional storage each time period, then it is your decision whether or not you accept that need. Peter Relson z/OS Core Technology Design -- 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
Re: Real Storage Occupancy
Ted, I am worried about if the real storage used more and more it will cause paging issue..is it right ? thanks. Wang Xiaobing. On Fri, 1 Jul 2011 21:16:04 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I find the problem is only real storage is increasing, virtual storage looks ok..can not understand why.. As I've tried to tell, this NOT a problem. Virtual storage is stable. There is no paging issue. So, what's the problem? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- 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 -- 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
Re: Real Storage Occupancy
If? If? If? Is it doing so? From your posts: NO. Monitor it if you really believe it is. But, I'd spend my time (better, IMO) monitoring the whole system, rather than monitoring a (maybe) pseudo issue. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Wang Xiaobing wang...@bayss.com Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Sun, 3 Jul 2011 20:14:35 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: Re: Real Storage Occupancy Ted, I am worried about if the real storage used more and more it will cause paging issue..is it right ? thanks. Wang Xiaobing. On Fri, 1 Jul 2011 21:16:04 +, Ted MacNEIL eamacn...@yahoo.ca wrote: I find the problem is only real storage is increasing, virtual storage looks ok..can not understand why.. As I've tried to tell, this NOT a problem. Virtual storage is stable. There is no paging issue. So, what's the problem? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- 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 -- 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 -- 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
Re: Real Storage Occupancy
Let me ask an obvious question has the monitoring program been checked to ensure that it isn't collecting the data or storing it improperly (thereby accumulating data)? Many performance monitors will allow you to see the data that is contained in the allocated storage, so if you are seeing an increased in allocated frames, then you should be able to examine their contents to see if it is new or replicated data, etc. ... Also, have you validated the reported data from the REXX program against another monitor just to ensure no errors are being shown? Adam -- 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
Re: Real Storage Occupancy
Thanks, TED and Kees.. The system is no paging..but I would like to know the reason. The Virtual Storage usage of the task - JCSOL is no increasing during the days.. Do you think it is normal ? thanks. Wang Xiaobing On Thu, 30 Jun 2011 09:59:45 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933-cardhu_decombobulator_blackberry.rim.net- 197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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 -- 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
Re: Real Storage Occupancy
On Thu, 30 Jun 2011 19:54:44 -0500, Dale R. Smith dale- sm...@columbus.rr.com wrote: On Wed, 29 Jun 2011 22:22:24 -0500, Wang Xiaobing wang...@bayss.com wrote: Hi, We use a rexx program invoking ISFAFD to monitor the BATCH JOB, it is a long term running address space. The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Are you using stems in this long running REXX program? If you are and they are not explicitly being dropped, then that could account for some/all of the increase in storage use. REXX does not free storage used for stem elements even if you reuse the same stem name, so you need to drop the stem explicity to have REXX free the storage used. This normally isn't a problem as most REXX programs only run for a short time and storage is freed when the program ends. In your case, the program doesn't end, so no storage is freed. For example: Do Forever ...some process creates REXX stem (say line.) ...process elements in stem (line.) Drop line. /* Free Storage for Stem line. */ End /* Do Forever */ -- Dale R. Smith -- 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 Dale, Thanks for you reply. I checked the program, looks like almost all stems have been explicitly DROPed...Anyway I will review the program again to see there is no missing. I find the problem is only real storage is increasing, virtual storage looks ok..can not understand why.. Wang Xiaobing. -- 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
Re: Real Storage Occupancy
Virtual storage used by the task won't increase unless new GETMAIN is issued. After initial GETMAIN the working set will increase as the task begins to access more pages without FREEMAIN. These days, as real storage is usually not a problem, it's possible that those pages will reside in central storage for a long time. I guess that's what you saw. So in my opinition, you should check the program logic to find the possible cause: do you declare more variables as time goes by and never FREEMAIN the no-longer-used ones? My two cents. Best Regards, Johnny Luo On Fri, Jul 1, 2011 at 10:59 PM, Wang Xiaobing wang...@bayss.com wrote: Thanks, TED and Kees.. The system is no paging..but I would like to know the reason. The Virtual Storage usage of the task - JCSOL is no increasing during the days.. Do you think it is normal ? thanks. Wang Xiaobing On Thu, 30 Jun 2011 09:59:45 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933-cardhu_decombobulator_blackberry.rim.net- 197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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 -- 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 -- 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
Re: Real Storage Occupancy
It's difficult to find the reason from the program logic...:-( Wang Xiaobing On Fri, 1 Jul 2011 23:15:04 +0800, Johnny Luo johnny.xingkui@gmail.com wrote: Virtual storage used by the task won't increase unless new GETMAIN is issued. After initial GETMAIN the working set will increase as the task begins to access more pages without FREEMAIN. These days, as real storage is usually not a problem, it's possible that those pages will reside in central storage for a long time. I guess that's what you saw. So in my opinition, you should check the program logic to find the possible cause: do you declare more variables as time goes by and never FREEMAIN the no-longer-used ones? My two cents. Best Regards, Johnny Luo On Fri, Jul 1, 2011 at 10:59 PM, Wang Xiaobing wang...@bayss.com wrote: Thanks, TED and Kees.. The system is no paging..but I would like to know the reason. The Virtual Storage usage of the task - JCSOL is no increasing during the days.. Do you think it is normal ? Â thanks. Wang Xiaobing On Thu, 30 Jun 2011 09:59:45 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933- cardhu_decombobulator_blackberry.rim.net- 197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. *** * For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 *** * -- 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 -- 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 -- 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 -- 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
Re: Real Storage Occupancy
It's not abnormal. Storage occupancy is next to meaningless if there's no paging. That's why IBM's recommendation is to set the SDC to ZERO. Your task is referencing pages and no other task needs more, so the RSM has no need to take them away. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -Original Message- From: Wang Xiaobing wang...@bayss.com Sender: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Date: Fri, 1 Jul 2011 09:59:45 To: IBM-MAIN@bama.ua.edu Reply-To: IBM Mainframe Discussion List IBM-MAIN@bama.ua.edu Subject: Re: Real Storage Occupancy Thanks, TED and Kees.. The system is no paging..but I would like to know the reason. The Virtual Storage usage of the task - JCSOL is no increasing during the days.. Do you think it is normal ? thanks. Wang Xiaobing On Thu, 30 Jun 2011 09:59:45 +0200, Vernooij, CP - SPLXM kees.verno...@klm.com wrote: Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933-cardhu_decombobulator_blackberry.rim.net- 197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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 -- 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 -- 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
Re: Real Storage Occupancy
I find the problem is only real storage is increasing, virtual storage looks ok..can not understand why.. As I've tried to tell, this NOT a problem. Virtual storage is stable. There is no paging issue. So, what's the problem? - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- 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
Re: Real Storage Occupancy
Ted MacNEIL eamacn...@yahoo.ca wrote in message news:1461128744-1309404933-cardhu_decombobulator_blackberry.rim.net-197 9920784-@b12.c1.bise6.blackberry... The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL Agreed, CS usage does not say much in general. However, in this case I assume that the task's virtual storage is also increasing during the days and that could/should be a better trigger to suspect problems in the task with its storage management. So, forget CS, check the Virtual Storage usage of the task. Kees. For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 -- 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
Re: Real Storage Occupancy
On Wed, 29 Jun 2011 22:22:24 -0500, Wang Xiaobing wang...@bayss.com wrote: Hi, We use a rexx program invoking ISFAFD to monitor the BATCH JOB, it is a long term running address space. The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Are you using stems in this long running REXX program? If you are and they are not explicitly being dropped, then that could account for some/all of the increase in storage use. REXX does not free storage used for stem elements even if you reuse the same stem name, so you need to drop the stem explicity to have REXX free the storage used. This normally isn't a problem as most REXX programs only run for a short time and storage is freed when the program ends. In your case, the program doesn't end, so no storage is freed. For example: Do Forever ...some process creates REXX stem (say line.) ...process elements in stem (line.) Drop line. /* Free Storage for Stem line. */ End /* Do Forever */ -- Dale R. Smith -- 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
Real Storage Occupancy
Hi, We use a rexx program invoking ISFAFD to monitor the BATCH JOB, it is a long term running address space. The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Service - Frame Occupancy - -- Active Frames -- AUX PGIN ES Jobname C Class TOTAL ACTV IDLE WSET FIXEDDIV SLOTS RATE RATE JSCOLS STCLO 18681 0 18681 0 332 0 000 JSCOLS STCLO 19631 0 19631 0 336 0 000 JSCOLS STCLO 26165 0 26165 0 499 0 000 JSCOLS STCLO 26861 0 26861 0 505 0 000 JSCOLS STCLO 30867 4652 26214 31016 562 0 000 JSCOLS STCLO 31886 0 31886 0 567 0 000 JSCOLS STCLO 36857 8132 28725 36965 590 0 000 JSCOLS STCLO 38122 0 38122 0 591 0 000 JSCOLS STCLO 38890 5834 33056 38896 591 0 000 JSCOLS STCLO 42842 0 42842 0 630 0 000 JSCOLS STCLO 44092 7957 36136 44204 634 0 000 JSCOLS STCLO 45171 6817 38355 45445 638 0 000 JSCOLS STCLO 60919 0 60919 0 694 0 000 JSCOLS STCLO 62220 0 62220 0 699 0 000 JSCOLS STCLO 62976 0 62976 0 713 0 000 JSCOLS STCLO 67255 5388 61867 67346 808 0 000 JSCOLS STCLO 68429 12345 56085 68581 806 0 000 JSCOLS STCLO 68963 0 68963 0 809 0 000 JSCOLS STCLO 72832 19684 53149 72902 887 0 000 JSCOLS STCLO 74052 13361 60691 74228 891 0 000 -- 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
Re: Real Storage Occupancy
The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Is it a problem? Are you paging? Occupancy varies depending on the workload mix. The SRM has a concept called lazy pages. In other words, if no other task needs the memory, the working set won't be trimmed. This is especially the case, these days, with large stores z/OS. - Ted MacNEIL eamacn...@yahoo.ca Twitter: @TedMacNEIL -- 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
Re: Real Storage Occupancy
Not a clue I have no idea what JSCOL is or what it does. Get you JCSOL systems guy involved as he needs to explain this issue (if it is an issue). Ed From: Wang Xiaobing wang...@bayss.com To: IBM-MAIN@bama.ua.edu Sent: Wed, June 29, 2011 10:22:24 PM Subject: Real Storage Occupancy Hi, We use a rexx program invoking ISFAFD to monitor the BATCH JOB, it is a long term running address space. The name is JCSOL, but we found the REAL STORAGE occupied by JCSOL is increased, almost 6000 frames per day. Can someone provide any train of thought to investigate this problem? TIA. Service - Frame Occupancy - -- Active Frames -- AUX PGIN ES Jobname C Class TOTAL ACTV IDLE WSET FIXEDDIV SLOTS RATE RATE JSCOLS STCLO 18681 0 18681 0 332 0 000 JSCOLS STCLO 19631 0 19631 0 336 0 000 JSCOLS STCLO 26165 0 26165 0 499 0 000 JSCOLS STCLO 26861 0 26861 0 505 0 000 JSCOLS STCLO 30867 4652 26214 31016 562 0 000 JSCOLS STCLO 31886 0 31886 0 567 0 000 JSCOLS STCLO 36857 8132 28725 36965 590 0 000 JSCOLS STCLO 38122 0 38122 0 591 0 000 JSCOLS STCLO 38890 5834 33056 38896 591 0 000 JSCOLS STCLO 42842 0 42842 0 630 0 000 JSCOLS STCLO 44092 7957 36136 44204 634 0 000 JSCOLS STCLO 45171 6817 38355 45445 638 0 000 JSCOLS STCLO 60919 0 60919 0 694 0 000 JSCOLS STCLO 62220 0 62220 0 699 0 000 JSCOLS STCLO 62976 0 62976 0 713 0 000 JSCOLS STCLO 67255 5388 61867 67346 808 0 000 JSCOLS STCLO 68429 12345 56085 68581 806 0 000 JSCOLS STCLO 68963 0 68963 0 809 0 000 JSCOLS STCLO 72832 19684 53149 72902 887 0 000 JSCOLS STCLO 74052 13361 60691 74228 891 0 000 -- 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 -- 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
