I am at zOS 2.4 level I am curious why does NONSMS is not spanning into second volume when the file is growing even though I gave AGGRGROW
On Tue, 27 Aug 2024, 19:48 David Spiegel, < 00000468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > Hi Peter, > Which z/OS are you running? > z/OS V2.5 does not support HFS (only zFS). > > Regards, > David > > > On 2024-08-27 11:36, Peter wrote: > > Hello > > > > These are things I did > > > > 1 ) allocated zfs mulitvolume with each mod 27 as NON SMS(so extended > data > > class as this more than 4g) - Failed > > > > 2 ) allocated hfs as mulitvolume and it failed again without spanning > > > > On Tue, 27 Aug 2024, 19:16 Keith Gooding, < > > 0000034af3894af4-dmarc-requ...@listserv.ua.edu> wrote: > > > >> Hi Peter > >> Remember that if you are expecting the ZFS to be automatically expanded > >> into secondary extents after initial formatting you must mount it with > the > >> AGGGROW attribute. > >> > >> Keith > >> > >> > >> > >>> On 27 Aug 2024, at 15:36, David Spiegel < > >> 00000468385049d1-dmarc-requ...@listserv.ua.edu> wrote: > >>> Hi Peter, > >>> Yes, because, the Data Class needs to have Extended attribute. > >>> > >>> Regards, > >>> David > >>> > >>> > >>>> On 2024-08-27 01:49, Peter wrote: > >>>> I tried with zfs primary 10000 and secondary 10000 but still it fails > >> with > >>>> no space. > >>>> > >>>> The multivolume works only in SMS managed ? > >>>> > >>>> On Mon, 26 Aug 2024, 09:19 Brian Westerman, < > >>>> 000006ba4ed225c9-dmarc-requ...@listserv.ua.edu> wrote: > >>>> > >>>>> Increasing the dataset you are increasing (SMPNTS) is only necessary > if > >>>>> you run out of space when downloading the service from IBM, your > >> problem is > >>>>> decompressing the compressed files that you already downloaded, so > you > >> only > >>>>> need to increase the //SMPWKDIR (defaults to /TMP) space. The one > you > >> use > >>>>> for "normal" operation is just too small for the service you are > >>>>> installing, and that happens a lot, especially with very large > service > >> like > >>>>> Java updates. > >>>>> > >>>>> I always allocate a new ZFS for service related temp space and don't > >> use > >>>>> the "normal" /tmp space (which is typically a tfs and not a "real" > zfs > >>>>> dataset anyway.) > >>>>> > >>>>> Just create a ZFS at about the size of your normal SMPNTS zfs > dataset, > >>>>> then create a new USS directory (use permissions of 777) called > "TEMP" > >> and > >>>>> mount the new zfs to that directory, then in your receive order or > >> Receive > >>>>> from NTS job, add the following DD. > >>>>> > >>>>> //SMPWKDIR DD PATHDISP=KEEP,PATH='/TEMP' (use the original /tmp > >> ONLY if > >>>>> extracts are small enough) > >>>>> > >>>>> Typically I allocate the /TEMP ZFS as 10,000 primary and 10,000 > >> secondary > >>>>> CYLS, and call it "OMVS.TEMP.ZFS" which should be big enough for just > >> about > >>>>> anything. > >>>>> > >>>>> When you are done, just unmount and delete the new ZFS > "OMVS.TEMP.ZFS". > >>>>> > >>>>> It doesn't really matter what name you call the ZFS, so long as you > >> tell > >>>>> SMPE that the //SMPWKDIR is to be allocated to the /TEMP directory > >> that you > >>>>> mounted it to. Then the service job will use that new "temporary" > zfs > >> that > >>>>> you created for decompression, instead of the (probably much smaller) > >> /tmp > >>>>> dataset. > >>>>> > >>>>> It's difficult to tell ahead of time how much temp space will be > >> necessary > >>>>> to decompress the PTFs, that's why I always make a new one. There is > >> no > >>>>> reason to keep it around when you are done with it, it will just take > >> up > >>>>> space that you can use for other things. You especially don't want > >> HSM to > >>>>> back it up or archive it because that will just waste resources. > >>>>> > >>>>> Brian > >>>>> > >>>>> > ---------------------------------------------------------------------- > >>>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>>>> > >>>> ---------------------------------------------------------------------- > >>>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>>> send email to lists...@listserv.ua.edu with the message: INFO > IBM-MAIN > >>> ---------------------------------------------------------------------- > >>> For IBM-MAIN subscribe / signoff / archive access instructions, > >>> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> ---------------------------------------------------------------------- > >> For IBM-MAIN subscribe / signoff / archive access instructions, > >> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > >> > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
