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
