Does GIMPAF can tell me how much it would decompress ? On Tue, 27 Aug 2024, 19:55 Radoslaw Skorupka, < 00000471ebeac275-dmarc-requ...@listserv.ua.edu> wrote:
> No, ZFS need NOT to be extended format and can be >4GB. > > ZFS can be Extended Addressability when non-SMS and non-extended format. > > Some notes: > 1. old HFS is no longer supported (since z/OS 2.5), however it could be > multi-vol. However HFS multi-vol had to be SMS-managed. > 2. HFS were never limited to 4GB. > 3. ZFS on SMS volume and size >4GB *has* to be extended format. That's a > problem when copying/moving. > > > > -- > Radoslaw Skorupka > Lodz, Poland > > > > W dniu 27.08.2024 o 16:35, David Spiegel pisze: > > 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
