Each spring and fall, I start clearing out the kid's small clothes, old toys, etc. It can sometimes go too far and reach into my "digital pack-rat" issues. (Wait, what does that mean? Well, just ask the person who last week requested detail on a project I worked 3 years ago, I keep everything hence my self-coined term "digital pack-rat".) My OLAP folder was getting messy because when OLAP cubes are refreshed in-place and users are still accessing the cube, a second generation of the cube is created.
For illustration purposes, I have included below a sample folder structure of a simple OLAP cube created from SASHELP.SHOES. The cube was created at 11:07am, then updated in-place at 11:15am. But at 11:18am, when I ran the update in-place code again I was still viewing the cube in SAS Enterprise Guide. Therefore, since the gen0001 folder was locked for viewing, a gen0002 folder was created. This is the back-end magic for update in-place to work correctly.
You can not just delete the old generational folder (gen0000) when everyone is done using it. Per the SAS OLAP documentation on archiving and deleting prior generations a cube's new generations typically look through prior generational folder. But cleaning up this folder isn't just for saving space or reducing a pack-rat's digital footprint, each version of the cube remains completely viable and can therefore become less efficient over time.
To combine everything back together, you will need to run a full refresh of the cube during off-hours (which adds its own complexity), or run an COALESCE_AGGREGATIONS option in PROC OLAP as shown below.
PROC OLAP CUBE = "/Projects/Cubes/Shoes" COALESCE_AGGREGATIONS;
More information on how to update cubes in place using SAS code is available in my prior post on OLAP refresh best practices.