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
