Re: Increase File size on system file held in LLA and XCFAS
May I assume (should it be obvious?) that the design is such that system resources can be sufficiently RACF-protected that a user lacking authority to update those resources can not threaten system integrity or security by failing to follow proper protocols, but only the integrity of that user's own resources and jobs? Sure. But of course can be is important. It is up to you (the customer) to set up the definitions properly. The system does only as good a job of protecting things as you have told it to do. If you have not properly protected important system data sets (such as, but not limited to, those in the LNKLST or LPALST or APF list), your system cannot be said to have any integrity at all. 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: Increase File size on system file held in LLA and XCFAS
Perhaps it is not obvious to some, though obvious to me. The only valid protocol for such operations as reallocation of space and compress is to use DISP=OLD (ENQ obtained exclusive). If you choose to do such operations with DISP=SHR then you get what you deserve (i.e., it might work but your system might well suffer for it, and you'll get little if any sympathy).. The system does not, indeed cannot, stop you. It can only try to protect you against cases where you follow proper protocols. 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: Increase File size on system file held in LLA and XCFAS
On Mon, 19 Nov 2007 07:21:50 -0500, Peter Relson wrote: Perhaps it is not obvious to some, though obvious to me. The only valid protocol for such operations as reallocation of space and compress is to use DISP=OLD (ENQ obtained exclusive). If you choose to do such operations with DISP=SHR then you get what you deserve (i.e., it might work but your system might well suffer for it, and you'll get little if any sympathy).. The system does not, indeed cannot, stop you. It can only try to protect you against cases where you follow proper protocols. May I assume (should it be ovious?) that the design is such that system resources can be sufficiently RACF-protected that a user lacking authority to update those resources can not threaten system integrity or security by failing to follow proper protocols, but only the integrity of that user's own resources and jobs? -- gil -- 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: Increase File size on system file held in LLA and XCFAS
On Sat, 17 Nov 2007 12:30:34 -0500, Peter Relson wrote: Removing the ENQ is easy. Increasing the size of an existing data set for which the system has obtained ENQs is not supported, and you do so at your own risk. The ENQ's are in place so that you do NOT do this. Apparently the key word here is system. I tried the experiment and readily performed secondary allocation with a batch job (IEBGENER SYSUT2) while my TSO session had the DSH allocated SHR. Does the system hold an exclusive ENQ to prevent this? -- gil -- 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: Increase File size on system file held in LLA and XCFAS
It is true that you can increase the size of a dataset that is OPEN by another address space after removing its ENQ protection, as you have obviously demonstrated with your experiment. However, you need to understand that the internal constructs representing that OPENed data set to the address space that had ENQueued it previously are not dynamically updated to show the existence of the new extent. The DEB (Data Extent Block) is created when the dataset is OPENed and only adds new extents when that same address space occurs an EOV (End Of Volume) condition during its own data set processing. Consequently, the new extent created by another address space in NOT recognized by the original owner without its CLOSEing and re-OPENing the data set. Mike Myers Mentor Services Corporation Paul Gilmartin wrote: On Sat, 17 Nov 2007 12:30:34 -0500, Peter Relson wrote: Removing the ENQ is easy. Increasing the size of an existing data set for which the system has obtained ENQs is not supported, and you do so at your own risk. The ENQ's are in place so that you do NOT do this. Apparently the key word here is system. I tried the experiment and readily performed secondary allocation with a batch job (IEBGENER SYSUT2) while my TSO session had the DSH allocated SHR. Does the system hold an exclusive ENQ to prevent this? -- gil -- 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 -- 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: Increase File size on system file held in LLA and XCFAS
Gil: See my previous reply. The DEB exists in the LSQA of the address space that has the data set OPEN. In order to do what you ask, it would be necessary for the system to find all OPEN instances of the newly extended data set and then adding the new extent to its particular DEB. How it would determine which address spaces have the data set OPEN without using GRS' Queue elements for that data set (which you affected by the DEQ), I don't know. You could partially solve the problem by holding DEBs in global storage, such as SQA, but this causes problems with the DEB's appendage exit list which provides for application specific exits associated with the use of the data set. Trying to make these global in scope would pose some problems, in particular, it opens up an integrity exposure (based on the DEB appendages) that was closed back in the first couple of years that MVS was in existence. Mike Myers Mentor Services Corporation Paul Gilmartin wrote: On Thu, 15 Nov 2007 15:53:49 -0600, Mark S. House wrote: During SMP/E mantenance a system fils CSF.SCSFMOD0 had a d37. I removed the file from the PLEX and wanted to increase it's size. It appears the LLA and XCFAS on the on the other LPAR's in the system have enque on the name. How can I remove the enqueue so I can increase and copy the file. Long ago, I encountered a technique, with DYNALLOC, to create a data set while another job holds a SHR ENQ on its DSN. I reported this in a PMR to IBM which struggled long and earnestly with the problem, and concluded it was too hard to fix, and presented a nuisance but no hazard. AFAIK, the behavior remains unchanged. -- gil -- 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 -- 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: Increase File size on system file held in LLA and XCFAS
On Thu, 15 Nov 2007 15:53:49 -0600, Mark S. House wrote: During SMP/E mantenance a system fils CSF.SCSFMOD0 had a d37. I removed the file from the PLEX and wanted to increase it's size. It appears the LLA and XCFAS on the on the other LPAR's in the system have enque on the name. How can I remove the enqueue so I can increase and copy the file. Long ago, I encountered a technique, with DYNALLOC, to create a data set while another job holds a SHR ENQ on its DSN. I reported this in a PMR to IBM which struggled long and earnestly with the problem, and concluded it was too hard to fix, and presented a nuisance but no hazard. AFAIK, the behavior remains unchanged. -- gil -- 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: Increase File size on system file held in LLA and XCFAS
On Sun, 18 Nov 2007 13:28:00 -0500, Mike Myers wrote: Gil: See my previous reply. The DEB exists in the LSQA of the address space that has the data set OPEN. In order to do what you ask, it would be I believe I asked nothing (except insofar as I quoted the OP); I merely offered two empirical observations. necessary for the system to find all OPEN instances of the newly extended data set and then adding the new extent to its particular DEB. How it would determine which address spaces have the data set OPEN without using GRS' Queue elements for that data set (which you affected by the DEQ), I don't know. Again, in neither of my postings did I mention a DEQ. I did no DEQ. You could partially solve the problem by holding DEBs in global storage, such as SQA, but this causes problems with the DEB's appendage exit list which provides for application specific exits associated with the use of the data set. Trying to make these global in scope would pose some problems, in particular, it opens up an integrity exposure (based on the DEB appendages) that was closed back in the first couple of years that MVS was in existence. And global would here necessarily mean through all systems in a plex. Paul Gilmartin wrote: On Thu, 15 Nov 2007 15:53:49 -0600, Mark S. House wrote: During SMP/E mantenance a system fils CSF.SCSFMOD0 had a d37. I removed the file from the PLEX and wanted to increase it's size. It appears the LLA and XCFAS on the on the other LPAR's in the system have enque on the name. How can I remove the enqueue so I can increase and copy the file. Long ago, I encountered a technique, with DYNALLOC, to create a data set while another job holds a SHR ENQ on its DSN. I reported this in a PMR to IBM which struggled long and earnestly with the problem, and concluded it was too hard to fix, and presented a nuisance but no hazard. AFAIK, the behavior remains unchanged. -- gil -- 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: Increase File size on system file held in LLA and XCFAS
Paul: OK, it looks like I missed your ENQ shared condition. On looking back, I see you just allocated the file DISP=SHR, which would allow you to OPEN it in another job and then extend it. Of course, you realize that you violated the purpose of the exclusive ENQ by updating the data set in one of the sharing instances. And you create the potential problem situation which I tried to describe. Mike Myers Mentor Services Corporation Paul Gilmartin wrote: On Sun, 18 Nov 2007 13:15:42 -0500, Mike Myers wrote: It is true that you can increase the size of a dataset that is OPEN by another address space after removing its ENQ protection, as you have obviously demonstrated with your experiment. I removed no ENQ protection. I suspect that to end an ENQ in another address space would require considerable privilege that my batch job lacked. Didn't my TSO session continue to hold the SHR ENQ on the DSN? However, you need to understand that the internal constructs representing that OPENed data set to the address space that had ENQueued it previously are not dynamically updated to show the existence of the new extent. Understood. Paul Gilmartin wrote: Apparently the key word here is system. I tried the experiment and readily performed secondary allocation with a batch job (IEBGENER SYSUT2) while my TSO session had the DSH allocated SHR. Does the system hold an exclusive ENQ to prevent this? -- gil -- 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 -- 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: Increase File size on system file held in LLA and XCFAS
On Sun, 18 Nov 2007 13:15:42 -0500, Mike Myers wrote: It is true that you can increase the size of a dataset that is OPEN by another address space after removing its ENQ protection, as you have obviously demonstrated with your experiment. I removed no ENQ protection. I suspect that to end an ENQ in another address space would require considerable privilege that my batch job lacked. Didn't my TSO session continue to hold the SHR ENQ on the DSN? However, you need to understand that the internal constructs representing that OPENed data set to the address space that had ENQueued it previously are not dynamically updated to show the existence of the new extent. Understood. Paul Gilmartin wrote: Apparently the key word here is system. I tried the experiment and readily performed secondary allocation with a batch job (IEBGENER SYSUT2) while my TSO session had the DSH allocated SHR. Does the system hold an exclusive ENQ to prevent this? -- gil -- 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: Increase File size on system file held in LLA and XCFAS
How can I remove the enqueue so I can increase and copy the file. Removing the ENQ is easy. Increasing the size of an existing data set for which the system has obtained ENQs is not supported, and you do so at your own risk. The ENQ's are in place so that you do NOT do this. If the system is using a LNKLST data set, you change the size of that data set at your own risk. The command to release the LNKLST ENQ's is provided solely so that you can access an uncataloged data set of the same name as a cataloged one currently in use. The right procedure, as has been covered many times involves first making sure that the data set is not in any active LNKLST set, which (if it involves doing a LNKLST UPDATE is unpredictably dangerous, and any problems that arise are yours to do with, and those problems could even range up to a wait state, so you get to decide what is more important to you.). Once the data set is not in any active LNKLST set, it will not be allocated by XCFAS. To get it out of LLA, you can either remove that data set from LLA management or stop and restart LLA. 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: Increase File size on system file held in LLA and XCFAS
- Original Message From: Mark S. House [EMAIL PROTECTED] How can I remove the enqueue so I can increase and copy the file. Mark, they only way I know to free others systems' ENQ is 1) P LLA on every system (frees LLA ENQs) 2) SETPROG LNKLST,UNALLOCATE on every system (free XCFAS ENQs) Once you are done with your activity on the dataset, issue 1) SETPROG LNKLST,ALLOCATE 2) S LLA,SUB=MSTR Walter Marguccio z/OS Systems Programmer Munich - Germany ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ -- 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: Increase File size on system file held in LLA and XCFAS
On Fri, 16 Nov 2007 06:30:48 -0800, Walter Marguccio [EMAIL PROTECTED] wrote: - Original Message From: Mark S. House [EMAIL PROTECTED] How can I remove the enqueue so I can increase and copy the file. Mark, they only way I know to free others systems' ENQ is 1) P LLA on every system (frees LLA ENQs) 2) SETPROG LNKLST,UNALLOCATE on every system (free XCFAS ENQs) Once you are done with your activity on the dataset, issue 1) SETPROG LNKLST,ALLOCATE 2) S LLA,SUB=MSTR Since you are dealing with a target (maintenance) data set, an alternate method would be to rename it via ISPF 3.4 VOLUME list. Even though it is ENQed, you can do this with the proper RACF authority (Search the archives of this list, ISPF-L, or google for more details). After you rename it you can do what you please (delete / re-alloc) and then rename it back. Obviously ... YOU NEED TO MAKE SURE YOU ARE NOT RENAMING THE REAL DATA SET. With the proper authority, for the rename, you could rename you live SYS1.LINKLIB and delete it... and the system will let you do so. Also, even if you want to do it the other way... there is no reason to stop LLA on every system (nor would you want to since that impacts performance). You can just create a CSVLLAxx member with REMOVE(data.set.name) and use F LLA,UPDATE=xx instead. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group - ZFUS G-ITO mailto:[EMAIL PROTECTED] z/OS Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- 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
Increase File size on system file held in LLA and XCFAS
During SMP/E mantenance a system fils CSF.SCSFMOD0 had a d37. I removed the file from the PLEX and wanted to increase it's size. It appears the LLA and XCFAS on the on the other LPAR's in the system have enque on the name. How can I remove the enqueue so I can increase and copy the file. Thanks. Mark House (402) 778-1966 IBM Mainframe Systems [EMAIL PROTECTED] This e-mail message and any attachments may contain confidential, proprietary or non-public information. This information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this e-mail, please notify the sender immediately and destroy this e-mail. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this e-mail are those of the author personally. -- 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
