Re: Free Up Unowned CSA/ECSA
In [EMAIL PROTECTED], on 09/03/2007 at 07:54 PM, Joel C. Ewing [EMAIL PROTECTED] said: Maybe I'm missing something here, but isn't it highly dangerous to assume just because CSA/ECSA is unowned that it is also unused and not referenced by some address pointer somewhere? No guts, no glory. It's a learning experience that will leave a far more vivid memory than any number of lectures. Besides, it's not our dog. IOW, you bet your sweet bippy it's dangerous. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- 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: Free Up Unowned CSA/ECSA
If TSO/E or any other IBM component obtains storage and intentionally leaves that storage after normal termination without specifying OWNER=SYSTEM, is it APARable? No. There is no statement in IBM publications that says that there should be no owner gone storage. But it won't hurt to bring it to that product's attention... Even if the storage is marked OWNER=SYSTEM, the CSA tracker should STILL retain the ownership information Sure it does. The individual piece is tracked, as is every individual piece. But the overall ownership information is maintained in a CAUB, one per owner. Adding an additional piece of OWNER=SYSTEM storage (as long as there is at least one, and there certainly is) causes no additional storage usage with respect to the overall ownership information. Peter Relson z/OS Core Technology Design -- 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: Free Up Unowned CSA/ECSA
I fully agree with the sentiment that you should not take it upon yourself to free common storage that someone else obtained unless you (somehow) are able to know 100% that it is not used. And I fully agree that unowned does not mean unused. Let me go a bit further, however, since unowned is not a category that the system has chosen to delineate. The categories that VSM supports are: owner=system owner=some-active-space identified at time of obtain owner gone The rule that we intended, and told everyone about, and tried (unsuccessfully in some cases) to get people to implement was: There should be no owner-gone storage. That meant that if you obtained common storage that needed to persist beyond the life of the obtainer, then it should not be owned by that space, but should be owner=system. Otherwise, you are wasting the space that the system must maintain in order to keep track of the fact that this now-gone space still owns storage. I personally would complain to a product owner who ended up with owner gone storage. They might blow you off, but perhaps they would (in my mind) fix (improve) their product. TSO/E was mentioned as one that obtains, and leaves stuff. Whether they do this or not, and whether they use OWNER=SYSTEM or not, I have no idea. But if they do that obtain, and do not specify OWNER=SYSTEM, then they could be prodded to update their code. Note that in z/OS 1.8, we implemented OwnerASID as an additional option to Home or Primary or Secondary or System to make it more likely that a server space, obtaining common storage while running within a client space (for example) could target the proper owning space. Peter Relson z/OS Core Technology Design -- 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: Free Up Unowned CSA/ECSA
On 5 Sep 2007 05:46:05 -0700, in bit.listserv.ibm-main you wrote: I fully agree with the sentiment that you should not take it upon yourself to free common storage that someone else obtained unless you (somehow) are able to know 100% that it is not used. And I fully agree that unowned does not mean unused. Let me go a bit further, however, since unowned is not a category that the system has chosen to delineate. The categories that VSM supports are: owner=system owner=some-active-space identified at time of obtain owner gone The rule that we intended, and told everyone about, and tried (unsuccessfully in some cases) to get people to implement was: There should be no owner-gone storage. That meant that if you obtained common storage that needed to persist beyond the life of the obtainer, then it should not be owned by that space, but should be owner=system. Otherwise, you are wasting the space that the system must maintain in order to keep track of the fact that this now-gone space still owns storage. I personally would complain to a product owner who ended up with owner gone storage. They might blow you off, but perhaps they would (in my mind) fix (improve) their product. TSO/E was mentioned as one that obtains, and leaves stuff. Whether they do this or not, and whether they use OWNER=SYSTEM or not, I have no idea. But if they do that obtain, and do not specify OWNER=SYSTEM, then they could be prodded to update their code If TSO/E or any other IBM component obtains storage and intentionally leaves that storage after normal termination without specifying OWNER=SYSTEM, is it APARable? -- 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: Free Up Unowned CSA/ECSA
Let me go a bit further, however, since unowned is not a category that the system has chosen to delineate. The categories that VSM supports are: owner=system owner=some-active-space identified at time of obtain owner gone The rule that we intended, and told everyone about, and tried (unsuccessfully in some cases) to get people to implement was: There should be no owner-gone storage. That meant that if you obtained common storage that needed to persist beyond the life of the obtainer, then it should not be owned by that space, but should be owner=system. Otherwise, you are wasting the space that the system must maintain in order to keep track of the fact that this now-gone space still owns storage. This does rankle me a bit. Even if the storage is marked OWNER=SYSTEM, the CSA tracker should STILL retain the ownership information (i.e., who obtained it). All too often, there is system owned storage that is involved in some CSA problem, be it an overlay or system malfunction. Knowing which address space obtained the storage originally (even if now gone) may assist in determining the component or ISV product involved in the problem. There is another capability that would be desirable and that is the concept of an ownership TRANSFER. A program that has obtained CSA may terminate abnormally, be restarted, and reuse the CSA that wasn't cleaned up when it failed, thereby making the storage no longer owner-gone, but it will still be marked so, as there is no way to transfer the ownership. Keith E. Moe Laid Back Software, Inc. http://www.laidbacksoftware.com (408) 749-0655 Creator of the TSO Environment and Administration Manager Product. Seeking employment and consulting opportunities with MVS. Located in Silicon Valley. Willing to Travel. Over 35 years in the industry (26 with one company). Resume: http://www.laidbacksoftware.com/resume.html Contact: [EMAIL PROTECTED] -- 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: Free Up Unowned CSA/ECSA
IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 09/05/2007 10:46:21 PM: Let me go a bit further, however, since unowned is not a category that the system has chosen to delineate. The categories that VSM supports are: owner=system owner=some-active-space identified at time of obtain owner gone The rule that we intended, and told everyone about, and tried (unsuccessfully in some cases) to get people to implement was: There should be no owner-gone storage. That meant that if you obtained common storage that needed to persist beyond the life of the obtainer, then it should not be owned by that space, but should be owner=system. Otherwise, you are wasting the space that the system must maintain in order to keep track of the fact that this now-gone space still owns storage. This does rankle me a bit. Even if the storage is marked OWNER=SYSTEM, the CSA tracker should STILL retain the ownership information (i.e., who obtained it). All too often, there is system owned storage that is involved in some CSA problem, be it an overlay or system malfunction. Knowing which address space obtained the storage originally (even if now gone) may assist in determining the component or ISV product involved in the problem. There is another capability that would be desirable and that is the concept of an ownership TRANSFER. A program that has obtained CSA may terminate abnormally, be restarted, and reuse the CSA that wasn't cleaned up when it failed, thereby making the storage no longer owner-gone, but it will still be marked so, as there is no way to transfer the ownership. I wrote down my wish list of VSM common storage tracking enhancements a few years ago, and actually did implement items 1 and 4 in z/OS 1.8. The things you are requesting look like items 2 and 3 on my list. I am currently trying to work on my Standalone Dump wish list, but maybe I will get back to my VSM list someday. 1. Owner=Asid 2. A Persistant attribute. This would be a new bit in the GQE, specified by the obtainer, to say that this storage is expected to remain after the owner terminates. Such storage would not be considered to be owner gone. 3. STORAGE TRANSFER,ADDR=area,LENGTH=length,OWNER=(new owner designation) This would look for a GQE which matches ADDR/LENGTH, and if it finds it, transfer ownership of the GQE from its current CAUB to the designated CAUB (i.e. subtract length from the current CAUB, add the length to the designated CAUB, and point the GQE to the designated CAUB. This function would require the caller to be authorized, and might be implemented only on the LINKAGE(SYSTEM) form of STORAGE (to save a bit of implementation cost). If no matching GQE is found, give a bad return code or ABEND(To Be Determined). This would be used by a component which terminates and restarts in a new address space to transfer ownership of persistant storage to the new address space. 4. A way to designate that the OWNER spcification should apply to the address space CAUB, (today we always use the current CAUB, which may be a job CAUB in an initiator address space). I have seen some cases where storage is obtained while a job CAUB is current which really belongs to the address space, and thus is flagged as owner gone when the job terminates. 5. In CPOOL, save the owning ASID in some CPOOL control block, and use this with OWNER=ASID when obtaining storage for a new extent (saw this issue not too long ago for some JES2 use of CPOOL). 6. Maybe add the proposed Persistant option to CPOOL BUILD. Jim Mulder z/OS System Test IBM Corp. Poughkeepsie, NY -- 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: Free Up Unowned CSA/ECSA
Maybe I'm missing something here, but isn't it highly dangerous to assume just because CSA/ECSA is unowned that it is also unused and not referenced by some address pointer somewhere? If you can determine the application that stranded the storage and know 100% that it should have freed the storage that is one thing; but there certainly used to be products that had an initialization process that would create something in CSA/ECSA to be used by later address spaces and then terminate. Freeing one of those types of storage areas would generally be bad news. [EMAIL PROTECTED] wrote: On Sep 3, 5:27 am, Jaleel [EMAIL PROTECTED] wrote: Is there a way to free up unowned(not realeased) CSA/ECSA storage ? Yes, you can free CSA if you want to write a program to do so. You can use Resource Measurement Facility (RMF) or a performance monitor from an ISV to display the storage allocation information that the storage tracking function collects. You can also use IPCS to get this info from a dump (i.e, VERBEXIT VSMDATA). By using RMF you can try to find out which jobs or address spaces are using an excessive amount of CSA storage or have ended without freeing CSA. However, this may work only for authorized programs which have included the OWNER parameter when issuing CPOOL BUILD, GETMAIN, and STORAGE OBTAIN macros that get storage in CSA. This means if you write your own program to free CSA, you will need to associate storage to be freed with an address space. Normally if an address space grabs CSA, it should have its own logic to release it unless the task needs to have the CSA storage remain persistent. This is where a task may be recycled several times within an IPL up-time, and the task needs an anchor block in CSA to reference upon start-up. Your program will need a combination of macros using VSMLIST,SPACE=UNALLOC,SP=CSA, plus you will need to write an analyze routine in your program for the VSMLIST report, and then MODESET to be in supervisor state, key 0, then SETLOCK OBTAIN,TYPE=CML for cross-memory lock, branch entry FREEMAINS, and SETLOCK RELEASE,TYPE=CML to release the lock. You must ensure you get it exact and you don't target an unintended area. There are ISV performance monitors that have this ability, and it may be better to use those than try to write your own. -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- 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: Free Up Unowned CSA/ECSA
Maybe I'm missing something here, but isn't it highly dangerous to assume just because CSA/ECSA is unowned that it is also unused and not referenced by some address pointer somewhere? YES (or NO)! DO NOT free it, unless you are the next coming of Christ, and you know! I have been there! Don't do it! I could show you my scars from when we tried it with OMEGAMON. It worked the first time. We were down for a day the second time! - Too busy driving to stop for gas! -- 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: Free Up Unowned CSA/ECSA
Please heed Ted's words. DO NOT free it! It cost me an IPL at 10am on a week day. On 9/3/07, Ted MacNEIL [EMAIL PROTECTED] wrote: Maybe I'm missing something here, but isn't it highly dangerous to assume just because CSA/ECSA is unowned that it is also unused and not referenced by some address pointer somewhere? YES (or NO)! DO NOT free it, unless you are the next coming of Christ, and you know! I have been there! Don't do it! I could show you my scars from when we tried it with OMEGAMON. It worked the first time. We were down for a day the second time! - Too busy driving to stop for gas! -- 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 -- I am as you, in you, for you. One as you in all, as all, forever. My call is your call. -- 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: Free Up Unowned CSA/ECSA
Ted MacNEIL wrote: Maybe I'm missing something here, but isn't it highly dangerous to assume just because CSA/ECSA is unowned that it is also unused and not referenced by some address pointer somewhere? YES (or NO)! DO NOT free it, unless you are the next coming of Christ, and you know! I have been there! Don't do it! I could show you my scars from when we tried it with OMEGAMON. It worked the first time. We were down for a day the second time! - Too busy driving to stop for gas! -- I too have been there and done that. There are products that will allocate CSA/ECSA and go away, but not free up the storage. They re-use it for other purposes. Unless it has changed, TSO is this way. It used to be the 1st TSO user allocates some CSA/ECSA that is not freed up when they logoff and is re-used over and over. If you free this up, TSO stops working. unowed is NOT the same as unused. -- 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
