Deleting Update Packages

Good Afternoon,

My question is can you delete an update package after a successful compression. And how many update packages to a parent can you go. We have a disk space problem and we are wondering if we can delete update packages to save on disk space.

John,

Part of the answer to your question depends on what kind of update packages you have, and how you manage them (i.e. do you deploy each one to all clients, or on an as-needed or departmental basis?).

For us, we build and deploy an update package usually about once every two to three weeks. We deploy the package to all clients, and monitor to ensure that all packages are accepted before we build our next update package. We've had cases in which packages can be applied out of chronological order, if more than one is waiting to be accepted at a client at a given time. If two or more of these packages had the same object, then you could end up with mis-aligned specs.

Since we monitor our update packages and keep on top of them being accepted, once all deployments are complete, we delete the update package. So at most we have one update package active for each environment at any given time.

Also, we don't use compression, as our network bandwidth is sufficient for deploying uncompressed updates, and therefore we don't have to go through the compression step. You may have different requirements, however, so you'll know best what works for you.

So, can you delete update packages? Yes, but only once you're done with them (deployments), and in your case, after you've compressed them.

I think what John was talking about when he said "compression" was recompressing the full package. The problem with doing that process is that everytime you build an update package, you would have to recompress the full and then use the full to deploy. Which takes more time than just using the update. What kind of a strategy are you using? For production, we keep the last full and all of its updates as far as a history goes. Then for all other environments we only keep the current full package and its updates. That keeps our deployment server's disk in check. Another way you could do it would be to create a tiered deploy server on some shared disk and use that for you deployments. That way you could delete the file structure on the original deploy server (Not the records within JDE), and if needed, copy it back to the original Deploy server.

Good luck!

Actually - you really should investigate using Windows compression on the package directories - you'll reclaim a LOT of space with zero issues.

On the deployment server - navigate to the PACKAGE directory for each pathcode, Right Click on it - click "Advanced" and "Compress" for all directories and files underneath.

Do not do this for other directories, since it will slow things down. However, there is no issue doing this for the package directories.

Don't delete the parents by the way - and I personally wouldn't delete the current series. I'd suggest you run a full package since it sounds like you have too many updates right now (which will produce serious performance issues)

Just as a hint to save (recover) disk space: you can always(!) delete the .pak files from full or update packages. They are of no more use once the package is build. This way you could save 1G for each full package you maintain on the DS.

My two centavos, Gerd

Jon, could you elaborate on the performance issues from update packages? I have seen this...wasn't entirely sure why...

Thanks

Ryan