New project named Globals for storing Global settings.

Do you have features you'd like to see in future releases of DataStage, MetaStage, Parameter Manager, Version Control or one of the other tools represented on this forum? Post your ideas here!

Moderators: chulett, rschirm

Post Reply
Ultramundane
Participant
Posts: 407
Joined: Mon Jun 27, 2005 8:54 am
Location: Walker, Michigan
Contact:

New project named Globals for storing Global settings.

Post by Ultramundane »

Please create a process by which a new project named Globals can be created. This new project named Globals, should contain all the environment variables by default and projects should inherit this settings first and then the local settings.

In addition, this project should be able to do much more than just this. This project should allow for parameters, parameter sets, jobs, etc... to be available in other projects as read only with the exception of the parameters and parameter sets of being able to modify their values.

Thus, should this project be defined and used, jobs defined must be exposed to all projects as Globals.name and be read only. Thus, other projects can invoke the jobs as though they were local and use parameters and parameter sets as though they were locally defined.

This allows for much more service oriented work and processes and to only have one copy of a process which may need to be shared amongst many projects.

As far as local settings, they take effect last.

As far as the uniqueness of jobs, if a job exists in any project and is named X, then this job should NOT be able to created in Globals. In addition, should X exist in globals, then it must not be allowed to be created locally. This for jobs. As far as parameters, parameters should still be able to be created/defined locally to override the Globals project. However, parameter sets, should follow the same process as jobs.

Thus, invoking a job with a parameter set parameter which is defined in Globals, should be allowed to be called via local project.parameter set. And, these jobs should be able to be invoked via local project and job name. The log for the job locally should be linked to globals log and available locally as well.

Thanks.
Ultramundane
Participant
Posts: 407
Joined: Mon Jun 27, 2005 8:54 am
Location: Walker, Michigan
Contact:

Re: New project named Globals for storing Global settings.

Post by Ultramundane »

Ultramundane wrote:Please create a process by which a new project named Globals can be created. This new project named Globals, should contain all the environment variables by default and projects should inherit this settings first and then the local settings.

In addition, this project should be able to do much more than just this. This project should allow for parameters, parameter sets, jobs, etc... to be available in other projects as read only with the exception of the parameters and parameter sets of being able to modify their values.

Thus, should this project be defined and used, jobs defined must be exposed to all projects as Globals.name and be read only. Thus, other projects can invoke the jobs as though they were local and use parameters and parameter sets as though they were locally defined.

This allows for much more service oriented work and processes and to only have one copy of a process which may need to be shared amongst many projects.

As far as local settings, they take effect last.

As far as the uniqueness of jobs, if a job exists in any project and is named X, then this job should NOT be able to created in Globals. In addition, should X exist in globals, then it must not be allowed to be created locally. This for jobs. As far as parameters, parameters should still be able to be created/defined locally to override the Globals project. However, parameter sets, should follow the same process as jobs.

Thus, invoking a job with a parameter set parameter which is defined in Globals, should be allowed to be called via local project.parameter set. And, these jobs should be able to be invoked via local project and job name. The log for the job locally should be linked to globals log and available locally as well.

Thanks.
This also allows job templates to be created one time and to be stored one time and to be exposed to other projects so that users can clone the template jobs for creating their processes. Thus, it is a big time savings when a job template has to be changed in a hundred projects which can now be changed just one time. Just change it in the Globals project and all projects will be exposed to the change.

Thanks.
Post Reply