Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL) - IBM AS400

This is a discussion on Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL) - IBM AS400 ; What would be the drawbacks of issuing the APYPTF LICPGM(*ALL) SELECT(*ALL) APY(*TEMP) DELAYED(*YES) IPLAPY(*YES) command. We are actually running short of disk space and we are at latest level of cumulative and all group ptfs we need since we download ...

+ Reply to Thread
Results 1 to 9 of 9

Thread: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

  1. Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    What would be the drawbacks of issuing the APYPTF LICPGM(*ALL) SELECT(*ALL)
    APY(*TEMP) DELAYED(*YES) IPLAPY(*YES) command.

    We are actually running short of disk space and we are at latest level
    of cumulative and all group ptfs we need since we download them (group ptfs)
    from IBM regularlly via SNDPTFORD.

    We'v already isued DLTPTF in order to suppress Q* savefiles from QGPL.



    Thanks in advance.







  2. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    Hi

    First draw back is that you are not likely to save any space, in order
    to cut down on PTF space you do better to apply the PTFs permanently.
    The draw back is that you would no longer be able to IPL without these
    PTFs being in affect, ie IPL from A & B would result in the same OS
    code being executed so there would be no way to remove a problem fix.

    That said, if you have been at your current PTF level for some time
    now without issue it should not be too bad. You would use APY(*PERM)
    to make this change.

    Other ideas you may want to consider:
    1) Check for any unused licpgms and remove these
    2) Run a RCLSTG
    3) Removed unwanted spools and run RCLSPLSTG DAYS(1)
    4) Remove unwanted DLOs and run RCLDLO DLO(*ALL)
    5) If you are using netserver Check IFS for crud
    6) Use the IBM PRTDSKINF tool to see what libraries are no longer used
    and remove them or move them to another ASP with disk compression on.
    7) Review disk protection, if you are using mirroring, could you
    survive with RAID, if you are using RAID could you reduce the number
    of arrays to reduce the amount of storage lost to parity striping.
    8) Could you live without the Object Operability and debug info in
    your program objects, if so remove it.

    Have said all that, 2nd user disk is sooo cheap you might want to
    consider an upgrade.

    Hope that helps. Sure a few of the others readers will have some other
    ideas.

    Cheers Brad


  3. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    Thanks again

    I really meant APY(*PERM) ... (problems of cutting and pasting

    About adding more disks we are not running RAID ... and I cannot add
    new ones as It is an old 170 with all bays ocupyed ... so what I was trying
    is to reduce disk ocupation (now it is at nearly 90%) and replace some old
    disks with bigger capacity ones (customer sourced). To do so .. I have to
    move all data from at least one disk to the rest of the ASP and replace and
    add to the ASP a new bigger one ... then STRASPBAL ... Except RCLDLO I have
    done all you mention plus RGZPFM and deleting LICPGMS like CL compiler
    support for previous releases, In V5R3M0 you can use RCLSPLSTG *NONE. Also
    done CPROBJ ..

    I am reluctant to remove the observable portion of *PGM since who knows
    when ... it may be needed for perhaps a future 128 bit processor achitecture
    migration. We had some nice experiences moving from cisc to risc .... but
    some failures due the lack of this portion of programs.











  4. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    On Jun 8, 12:48 pm, "CENTRINO" wrote:
    > Thanks again
    >
    > I really meant APY(*PERM) ... (problems of cutting and pasting
    >
    > About adding more disks we are not running RAID ... and I cannot add
    > new ones as It is an old 170 with all bays ocupyed ... so what I was trying
    > is to reduce disk ocupation (now it is at nearly 90%) and replace some old
    > disks with bigger capacity ones (customer sourced). To do so .. I have to
    > move all data from at least one disk to the rest of the ASP and replace and
    > add to the ASP a new bigger one ... then STRASPBAL ... Except RCLDLO I have
    > done all you mention plus RGZPFM and deleting LICPGMS like CL compiler
    > support for previous releases, In V5R3M0 you can use RCLSPLSTG *NONE. Also
    > done CPROBJ ..
    >
    > I am reluctant to remove the observable portion of *PGM since who knows
    > when ... it may be needed for perhaps a future 128 bit processor achitecture
    > migration. We had some nice experiences moving from cisc to risc .... but
    > some failures due the lack of this portion of programs.


    You could always 'just' take backups of stuff you want to change like
    removing observable data so you still have the real thing in case its
    needed later. If your tapes are worn you can save thinngs to savf then
    copy to a pc via ftp & make more backups onto say usb flash memory. If
    you just need the space for a while to swap to larger disk then I
    would think this is a solution, except you need the space for the 1st
    item backed up before its deleted. Oh.

    Jonathan.


  5. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    After APYPTF LICPGM(*ALL) SELECT(*ALL)APY(*PERM) DELAYED(*YES) IPLAPY(*YES)
    and one hour of IPL:

    From 89% out of 25GB to 68% Some 5GB Gain just in temporary PTFs

    Hope it helps.

    V5R3M0





  6. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    CENTRINO wrote:

    > After APYPTF LICPGM(*ALL) SELECT(*ALL)APY(*PERM) DELAYED(*YES) IPLAPY(*YES)
    > and one hour of IPL:
    >
    > From 89% out of 25GB to 68% Some 5GB Gain just in temporary PTFs


    Unless you have been IPLing regularly, I wouldn't expect that much of
    the gain had to do with PTFs. If IPLs haven't been regular, perhaps
    weekly even, then most of the 5GB was possibly simple recovery of normal
    temporary space.

    If IPLs have been done every few days, then it's unlikely that much
    temporary space was being used. Long-running jobs such as various server
    apps would have their joblogs flushed often, objects in all the QTEMPs
    would be released, etc.

    Watch the space utilization for a week or so to see if it trends back up
    towards 89%. I would expect to see it up near 80% by next week sometime
    on many systems; perhaps more.

    Now that PTFs are applied *PERM, you would use DLTPTF to clean up PTF
    savefiles. These could be leftovers from older releases or savefiles
    from PTFs that hadn't been loaded/applied yet. Deleting the savefiles
    before loading and applying would mean they'd need to be downloaded
    again, if they ever were needed.

    If you have Service Director (or whatever it's called in your version)
    running, some or even most of the PTF savefiles might have been
    downloaded in response to problems your system found. If the problem log
    isn't reviewed or other means of being notified aren't used, the PTFs
    might never be noticed and the fixes never applied.

    --
    Tom Liotta
    http://zap.to/tl400

  7. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    I am so surpriced as you are ....

    Our 170 IPL every day

    What I must say is that I am, as system administrator, a "PTF addict" ...
    and that the machine have been upgraded with OS from V4R5M0 and regularly
    PTF updated.

    I issued DLTPTF before APYPTF and the gain was a 5GB just with APYPTF !!!

    It makes me think that IBM should implement a way to let us know how much
    disk space is spared by temporary patches.

    If you know some procedure to determine such a thing let me know.

    What it really made me think about applying PTFs permanetlly was the ever
    encreasing disk occupation after downloading or applying cumulative or group
    PTFs



  8. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    CENTRINO wrote:

    > I am so surpriced as you are ....
    >
    > Our 170 IPL every day


    If there's been little cleanup for a few releases, then maybe it's not
    as surprising. Or if entire cumes and groups have been held on-line,
    that would also help account for it. 5GB isn't really a lot -- 6 CDs or
    a bit over a single DVD.

    Still, I agree there is room for improvement in automatic cleanup. I
    haven't had to think about that for a while, but it doesn't seem like it
    would take much to get some decent improvement in what's built in to
    OS/400 or i5/OS. I'll have to think about that.

    As it is, though, it's much better than trying to clean stuff up after
    months of Windows downloads/patches. Those who I ask keep telling me to
    avoid deleting at all any of the hidden directories that build up in the
    Windows system directory. I'm glad that PC disk is cheap but irritated
    that I have to have so much just to keep a system patched.

    --
    Tom Liotta
    http://zap.to/tl400

  9. Re: Running short of disk and APYPTF LICPGM(*ALL) SELECT(*ALL)

    At least IBM has a way to clean up the mess not the way MS windows does

    I've been working with S/38 and AS/400 - System I since 1988. Very few
    times I have had to remove a PTF becouse it is defective or any other
    installation failure, but also never have had to apply permanently all
    system and licpgms PTFs, and what a discovery! I'd agree with you that in
    automatic cleanup an option should be setup in order to automatically
    permanently apply elder PTFs



+ Reply to Thread