Sharing disk and scratchdisk between multiple projects

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

Post Reply
kdthomas
Premium Member
Premium Member
Posts: 5
Joined: Tue Oct 09, 2007 11:05 am

Sharing disk and scratchdisk between multiple projects

Post by kdthomas »

Hi everyone,

Our team currently has "dev" and "test" projects configured on a single SMP box. This box is dedicated to running DataStage only...no other applications are running on it. Each of these projects currently has its own configuration file pointing to dedicated disk and scratchdisk resources. Due to an acute shortage of disk space (which will not be resolved soon), we're looking at combining these resources into a single larger resource and sharing them between the two projects to help alleviate the problem.

We don't believe there will be a lot of resource contention between dev and test: Dev is used by our team in India; test is used by our U.S.-based folks. Code is promoted from dev to test for QA purposes then moved into higher environments. The work between dev and test is highly independent and we're willing to live with the risk of having occasional overlapping resource demands in order to increase the size of our disk and scratchdisk resources.

Thus, our initial thoughts are to have our Unix sys admins combine the disk resources, create new configuration files and then clone them into each project and have the respective APT_CONFIG_FILE variables point to them.

One of our team members voiced a concern about the situation where the exact same job may be running in both environments and whether there might be a dataset clash on the resource disks somewhere. I've done a fair amount of investigation and I'm under the impression that DataStage should manage this with no issues because the jobs are in separate projects.

Therefore, other than the risk of contention between projects, are there other issues we should consider before making this decision? Are there any fatal flaws in our thought process so far?

I should also add that job performance is not an issue...the current code execution times are sufficient to meet our SLAs.

In advance, thanks for any suggestions anyone might have.
ray.wurlod
Participant
Posts: 54595
Joined: Wed Oct 23, 2002 10:52 pm
Location: Sydney, Australia
Contact:

Post by ray.wurlod »

The obvious one, that you probably don't have enough disk space even for one project, springs immediately to mind. Regularly make sure that files are being cleaned up from scratch disk (particularly if jobs abort).
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
kdthomas
Premium Member
Premium Member
Posts: 5
Joined: Tue Oct 09, 2007 11:05 am

Post by kdthomas »

Yes...good point. We've talked about the importance of minimizing datasets, but emphasizing clean-up is always a good thing...thanks.
Post Reply