Re: SMS-releasing unused space
Natasa, Are you fixing something that is not broken? What does it matter if the dataset has 5, 10 or 50 extents. Reducing extents is not actually making anything faster or more robust - especially if it is used by DFSORT. If the dataset varies from 10-300 CYLS on a daily basis then I would suggest 1 of two options: 1) Allocate with SPACE=(CYL,(350,35),RLSE) or 2) Allocate with SPACE=(CYL,(50,50),RLSE) In regards to your initial problem, is there anything that primes the dataset with a record or open/closes the file before DFSORT accesses it. If DFHSM is releasing the space then I would expect an empty dataset to go to zero Primary and not one CYL. Auditing the Type1415 SMF records will give you an idea of what is closing this file and releasing space. Ron > -Original Message- > From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On > Behalf Of Natasa Savinc > Sent: Tuesday, May 06, 2008 6:47 AM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: [IBM-MAIN] SMS-releasing unused space > > Daniel, > > because the size of the dataset is one day 200 cyl, another day 300 cyl > or > more, and during the weekend 10 cly. When we had RLSE, number of > extents > was steadily growing. > > Regards, > Natasa > > -- > 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: SMS-releasing unused space
Tom, we just overwrite it with the next run Robert, we don't have STOPX37, SRS or similar products. The attributes of MCNORLSE are : Expire after Days Non-usage . : NOLIMIT Expire after Date/Days . . . . : NOLIMIT Retention Limit . . . . . . . : NOLIMIT Partial Release . . . . . . : NO Migration Attributes Primary Days Non-usage . : Level 1 Days Date/Days . : 0 Command or Auto Migrate . : COMMAND Backup Attributes Backup frequency . . . . . . . . . . . : 0 Number of backup versions . . . . . . . : 2 (Data Set Exists) Number of backup versions . . . . . . . : 1 (Data Set Deleted) Retain days only backup version . . . . : 90 (Data Set Deleted) Retain days extra backup versions . . . : 90 Admin or User Command Backup . . . . . : BOTH Auto Backup . . . . . . . . . . . . . . : YES Backup copy technique . . . . . . . . . : STANDARD I allocated the dataset yesterday again, and made sure that it was allocated according to my specification: 200/20. Today, after it was populated with data, and after space mgmt, the dataset has still primary extent 200 cyl, used 183, which is what I would expect. Regards, Natasa -- 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: SMS-releasing unused space
On 6 May 2008 06:30:03 -0700, in bit.listserv.ibm-main you wrote: >Here is additional information: >The dataset was allocated through ISPF panels (so there was no RLSE >parameter), in subsequent daily batch it is used with DISP=OLD, program is >ICEMAN. Unless things have changed, there is a RLSE parameter on the Allocation panel which comes into play when the data set is closed in ISPF. >Management class MCNORLSE does not allow any migration, because those >datasets are used every day. >Regarding fragmentation, there are some very fragmented volumes in this >storage group, but there were certainly volumes available that had 200 cyl >extent free. > >Regards, >Natasa > >-- >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: SMS-releasing unused space
- Storage space constraint relief could cause this which is why I suggested looking at fragmentation. I probably should have included amount of free space on the volume or in the SMS pool. I submit that if there was enough free space to accumulate 11 secondary extents of 20 cylinders each that fragmentation or constraint relief are not issues here. I, too, want to see the actual DD statement that made the allocation. -- 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: SMS-releasing unused space
Natasa, Can you show us the MCNORLSE attributes? Also, do you have STOPX37, SRS or similar products? These products have the ability to manipulate allocations. Bob -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Natasa Savinc Sent: Tuesday, May 06, 2008 9:56 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: SMS-releasing unused space John, I will see about DAF, thank you for the information. The idea was to allocate the dataset manually, in order to assign it new MC, and to avoid changing daily batch and ACS routines. I allocated it again, and this time I checked actual allocation: General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 200 Storage class . . . : MEDIUM Allocated extents . : 1 Volume serial . . . : SSP100 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 0 Record format . . . : FB Used extents . . . : 0 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 200 Secondary cylinders : 20 Data set name type :SMS Compressible : NO We'll see what happens tomorrow. Regards, Natasa -- 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: SMS-releasing unused space
On Tue, 6 May 2008 08:46:53 -0500, Natasa Savinc wrote: > >because the size of the dataset is one day 200 cyl, another day 300 cyl or >more, and during the weekend 10 cly. When we had RLSE, number of extents >was steadily growing. You reuse this data set? How do you empty it to prepare for the next run? Perhaps that is what is releasing the space. -- Tom Marchant -- 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: SMS-releasing unused space
Daniel, allocation was 200/20. My question was something like "where did this 1 come from?" Regards, Natasa -- 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: SMS-releasing unused space
John, I will see about DAF, thank you for the information. The idea was to allocate the dataset manually, in order to assign it new MC, and to avoid changing daily batch and ACS routines. I allocated it again, and this time I checked actual allocation: General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 200 Storage class . . . : MEDIUM Allocated extents . : 1 Volume serial . . . : SSP100 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 0 Record format . . . : FB Used extents . . . : 0 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 200 Secondary cylinders : 20 Data set name type :SMS Compressible : NO We'll see what happens tomorrow. Regards, Natasa -- 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: SMS-releasing unused space
If that is known then 1 cylinder primary is automatically too small. Why nott 20/200? Daniel McLaughlin Z-Series Systems Programmer Information & Communications Technology Crawford & Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List wrote on 05/06/2008 09:46:53 AM: > -- Information from the mail header > --- > Sender: IBM Mainframe Discussion List > Poster: Natasa Savinc <[EMAIL PROTECTED]> > Subject: Re: SMS-releasing unused space > --- > > Daniel, > > because the size of the dataset is one day 200 cyl, another day 300 cyl or > more, and during the weekend 10 cly. When we had RLSE, number of extents > was steadily growing. > > Regards, > Natasa > > -- > 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 > > Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: SMS-releasing unused space
On Tue, 6 May 2008 09:05:34 -0400, John Kington wrote: >Tom Marchant wrote: >> >>I think it's unlikely that the volume is so fragmented that the first >>extent allocated was only 1 cylinder, but that he was able to >>obtain a total of 220 cylinders in 12 extents. It is especially >>unlikely considering that the secondary allocation is 20 cylinders. > >My understanding is that allocation is using first fit strategy and the >first extent could be only one cylinder if the next four extents equal or >exceed 249 cylinders. First fit may very well be the strategy that is used, but DADSM tries to provide the primary allocation in one extent. I always thought that when the primary allocation had to be done in multiple extents that the first extent is the largest. Perhaps someone will correct me if I'm mistaken. >The primary allocation amount for nonvsam datasets is >not retained after the creating job completes. That is true. -- Tom Marchant -- 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: SMS-releasing unused space
Daniel, because the size of the dataset is one day 200 cyl, another day 300 cyl or more, and during the weekend 10 cly. When we had RLSE, number of extents was steadily growing. Regards, Natasa -- 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: SMS-releasing unused space
Natasa, > Here is additional information: > The dataset was allocated through ISPF panels (so there was no RLSE > parameter), in subsequent daily batch it is used with DISP=OLD, program is > ICEMAN. > Management class MCNORLSE does not allow any migration, because those > datasets are used every day. > Regarding fragmentation, there are some very fragmented volumes in this > storage group, but there were certainly volumes available that had 200 cyl > extent free. I would highly recommend getting Dataset Audit Facility (DAF) from cbttape.org and run the SMF records through it to build a history of the dataset. This history might tell you what happened and when. Since you appear to be allocating these datasets manually, can you check the space information just after you create them? Regards, John -- 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: SMS-releasing unused space
It sounds up front as if the allocation was not estimated well enough in advance. Why not the 20 cylinders primary and 20 cylinders secondary with a RLSE? Daniel McLaughlin Z-Series Systems Programmer Information & Communications Technology Crawford & Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com IBM Mainframe Discussion List wrote on 05/06/2008 09:29:33 AM: > -- Information from the mail header > --- > Sender: IBM Mainframe Discussion List > Poster: Natasa Savinc <[EMAIL PROTECTED]> > Subject: Re: SMS-releasing unused space > --- > > Here is additional information: > The dataset was allocated through ISPF panels (so there was no RLSE > parameter), in subsequent daily batch it is used with DISP=OLD, program is > ICEMAN. > Management class MCNORLSE does not allow any migration, because those > datasets are used every day. > Regarding fragmentation, there are some very fragmented volumes in this > storage group, but there were certainly volumes available that had 200 cyl > extent free. > > Regards, > Natasa > > -- > 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 > > Best Overall Third-Party Claims Administrator - 2007 "Business Insurance" Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- 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: SMS-releasing unused space
Here is additional information: The dataset was allocated through ISPF panels (so there was no RLSE parameter), in subsequent daily batch it is used with DISP=OLD, program is ICEMAN. Management class MCNORLSE does not allow any migration, because those datasets are used every day. Regarding fragmentation, there are some very fragmented volumes in this storage group, but there were certainly volumes available that had 200 cyl extent free. Regards, Natasa -- 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: SMS-releasing unused space
Tom, > On Tue, 6 May 2008 08:25:42 -0400, John Kington wrote: > > >Natasa wrote: > > > > > >> Hello, > >> in order to prevent releasing of unused space for some datasets, I > >> allocated it > >> yesterday with MC that has Partial release parameter set to 'No'. > >However, > >> today when I look at some of those datasets, they look like the space was > > > >> first released (primary extent is 1 cyl, allocated was 200), and then as > >the > >> data was loaded it took 11 secondary extents. This is exactly what I > >wanted > >> to prevent. Can someone explain to me how this happened? > >> > >> General Data Current Allocation > >> Management class . . : MCNORLSE Allocated cylinders : 221 > >> Storage class . . . : MEDIUM Allocated extents . : 12 > >> Volume serial . . . : SSP122 > >> Device type . . . . : 3390 > >> Data class . . . . . : DCDYNV Current Utilization > >> Organization . . . : PS Used cylinders . . : 204 > >> Record format . . . : FB Used extents . . . : 12 > >> Record length . . . : 3000 > >> Block size . . . . : 27000 > >> 1st extent cylinders: 1 > >> Secondary cylinders : 20 > >> Data set name type :SMS Compressible : NO > >> > > > >The fact that the allocated cylinders is greater than the used cylinders > >(221 > 204) leads me to believe that space was not released from the > >dataset (allocated cylinders would equal used cylinders). The 1st extent is > >just the size of the first extent and not the primary space allocation > >amount. Each allocation can be up to five extents, even more if you are > >using the storage space constraint relief features of SMS. I recommend you > >look at the fragmentation index on your volume(s) and run some defrags. > > I think it's unlikely that the volume is so fragmented that the first extent > allocated was only 1 cylinder, but that he was able to obtain a total of 220 > cylinders in 12 extents. It is especially unlikely considering that > the secondary > allocation is 20 cylinders. My understanding is that allocation is using first fit strategy and the first extent could be only one cylinder if the next four extents equal or exceed 249 cylinders. The primary allocation amount for nonvsam datasets is not retained after the creating job completes. > > It is more likely that something caused the primary allocation to be > 1 cylinder > with 11 secondary allocations of 20 cylinders each. Storage space constraint relief could cause this which is why I suggested looking at fragmentation. I probably should have included amount of free space on the volume or in the SMS pool. > > There is not enough information to guess how this might have happened. > I agree. If the OP has access to Dataset Audit Facility (DAF) from cbttape.org, the tale could be told. Regards, John -- 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: SMS-releasing unused space
Natasa, Could you post the DD statement that created the file? I suspect we'll find a RLSE coded with the Space parameter. -- 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: SMS-releasing unused space
On Tue, 6 May 2008 08:25:42 -0400, John Kington wrote: >Natasa, > > >> Hello, >> in order to prevent releasing of unused space for some datasets, I >> allocated it >> yesterday with MC that has Partial release parameter set to 'No'. >However, >> today when I look at some of those datasets, they look like the space was > >> first released (primary extent is 1 cyl, allocated was 200), and then as >the >> data was loaded it took 11 secondary extents. This is exactly what I >wanted >> to prevent. Can someone explain to me how this happened? >> >> General Data Current Allocation >> Management class . . : MCNORLSE Allocated cylinders : 221 >> Storage class . . . : MEDIUM Allocated extents . : 12 >> Volume serial . . . : SSP122 >> Device type . . . . : 3390 >> Data class . . . . . : DCDYNV Current Utilization >> Organization . . . : PS Used cylinders . . : 204 >> Record format . . . : FB Used extents . . . : 12 >> Record length . . . : 3000 >> Block size . . . . : 27000 >> 1st extent cylinders: 1 >> Secondary cylinders : 20 >> Data set name type :SMS Compressible : NO > >The fact that the allocated cylinders is greater than the used cylinders >(221 > 204) leads me to believe that space was not released from the >dataset (allocated cylinders would equal used cylinders). The 1st extent is >just the size of the first extent and not the primary space allocation >amount. Each allocation can be up to five extents, even more if you are >using the storage space constraint relief features of SMS. I recommend you >look at the fragmentation index on your volume(s) and run some defrags. > It seems implausible that if the volume is so fragmented that only one cylinder was available for the first extent, 20 cylinders were available for each of 11 following extents. Other possibilities: o The data set was migrated and recalled between allocation and use. o You didn't say what program populated the data set. I have an open PMR on very similar misbehavior by /bin/cp which has resulted in New Function APAR PK64372. (Development saw no way to repair the problem without changing a default behavior.) -- 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: SMS-releasing unused space
Natasa, >in order to prevent releasing of unused space for some datasets, I allocated it >yesterday with MC that has Partial release parameter set to 'No'. However, >today when I look at some of those datasets, they look like the space was >first released (primary extent is 1 cyl, allocated was 200), and then as the >data was loaded it took 11 secondary extents. This is exactly what I wanted >to prevent. Can someone explain to me how this happened? Is it possible that the data set was migrated/recalled before loading? >From DFSMShsm Storage Administration Guide: 2. The PARTIAL RELEASE attribute does not apply to normal migration and recall processing. Related reading: For more information about migration and recall space allocation, see "Additional Space Management during Migration and Recall When DFSMShsm Is the Data Mover" in topic 2.1.21.7. Regards, Hermann -- 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: SMS-releasing unused space
On Tue, 6 May 2008 08:25:42 -0400, John Kington wrote: >Natasa wrote: > > >> Hello, >> in order to prevent releasing of unused space for some datasets, I >> allocated it >> yesterday with MC that has Partial release parameter set to 'No'. >However, >> today when I look at some of those datasets, they look like the space was > >> first released (primary extent is 1 cyl, allocated was 200), and then as >the >> data was loaded it took 11 secondary extents. This is exactly what I >wanted >> to prevent. Can someone explain to me how this happened? >> >> General Data Current Allocation >> Management class . . : MCNORLSE Allocated cylinders : 221 >> Storage class . . . : MEDIUM Allocated extents . : 12 >> Volume serial . . . : SSP122 >> Device type . . . . : 3390 >> Data class . . . . . : DCDYNV Current Utilization >> Organization . . . : PS Used cylinders . . : 204 >> Record format . . . : FB Used extents . . . : 12 >> Record length . . . : 3000 >> Block size . . . . : 27000 >> 1st extent cylinders: 1 >> Secondary cylinders : 20 >> Data set name type :SMS Compressible : NO >> > >The fact that the allocated cylinders is greater than the used cylinders >(221 > 204) leads me to believe that space was not released from the >dataset (allocated cylinders would equal used cylinders). The 1st extent is >just the size of the first extent and not the primary space allocation >amount. Each allocation can be up to five extents, even more if you are >using the storage space constraint relief features of SMS. I recommend you >look at the fragmentation index on your volume(s) and run some defrags. I think it's unlikely that the volume is so fragmented that the first extent allocated was only 1 cylinder, but that he was able to obtain a total of 220 cylinders in 12 extents. It is especially unlikely considering that the secondary allocation is 20 cylinders. It is more likely that something caused the primary allocation to be 1 cylinder with 11 secondary allocations of 20 cylinders each. There is not enough information to guess how this might have happened. -- Tom Marchant -- 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: SMS-releasing unused space
Natasa, > Hello, > in order to prevent releasing of unused space for some datasets, I > allocated it > yesterday with MC that has Partial release parameter set to 'No'. However, > today when I look at some of those datasets, they look like the space was > first released (primary extent is 1 cyl, allocated was 200), and then as the > data was loaded it took 11 secondary extents. This is exactly what I wanted > to prevent. Can someone explain to me how this happened? > > General Data Current Allocation > Management class . . : MCNORLSE Allocated cylinders : 221 > Storage class . . . : MEDIUM Allocated extents . : 12 > Volume serial . . . : SSP122 > Device type . . . . : 3390 > Data class . . . . . : DCDYNV Current Utilization > Organization . . . : PS Used cylinders . . : 204 > Record format . . . : FB Used extents . . . : 12 > Record length . . . : 3000 > Block size . . . . : 27000 > 1st extent cylinders: 1 > Secondary cylinders : 20 > Data set name type :SMS Compressible : NO > > Regards, > Natasa > > -- > 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 > The fact that the allocated cylinders is greater than the used cylinders (221 > 204) leads me to believe that space was not released from the dataset (allocated cylinders would equal used cylinders). The 1st extent is just the size of the first extent and not the primary space allocation amount. Each allocation can be up to five extents, even more if you are using the storage space constraint relief features of SMS. I recommend you look at the fragmentation index on your volume(s) and run some defrags. Regards, John -- 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
SMS-releasing unused space
Hello, in order to prevent releasing of unused space for some datasets, I allocated it yesterday with MC that has Partial release parameter set to 'No'. However, today when I look at some of those datasets, they look like the space was first released (primary extent is 1 cyl, allocated was 200), and then as the data was loaded it took 11 secondary extents. This is exactly what I wanted to prevent. Can someone explain to me how this happened? General Data Current Allocation Management class . . : MCNORLSE Allocated cylinders : 221 Storage class . . . : MEDIUM Allocated extents . : 12 Volume serial . . . : SSP122 Device type . . . . : 3390 Data class . . . . . : DCDYNV Current Utilization Organization . . . : PS Used cylinders . . : 204 Record format . . . : FB Used extents . . . : 12 Record length . . . : 3000 Block size . . . . : 27000 1st extent cylinders: 1 Secondary cylinders : 20 Data set name type :SMS Compressible : NO Regards, Natasa -- 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
