All,
I have a couple of questions. First is that I went to use the DS Scheduling piece for the first time and found that it doesn't have all the capabilities that I need. For instance I have a job that needs to run on a quarterly basis in Feb, May, Aug, and Nov but there is no way to do this (that I can see) Can anyone help with this?
My second question is that we need some dependancies between DS Server and some COBOL MF jobs. Is there a Distributed Systems Scheduler that would work to maintain both MF and DS? Does anyone have anything in place? I have heard about CA-7, but not sure on details.
My last question is, is there a way to set up Version Control access on projects for users to only check components out of Version Control but not write them into Version Control. I didn't know if we could set up user access to the "Version" project for users to only read from the project and not write to.
Any help with any of these questions would be a great help.
Thanks,
JB
Scheduling / Access
Moderators: chulett, rschirm, roy
-
vmcburney
- Participant
- Posts: 3593
- Joined: Thu Jan 23, 2003 5:25 pm
- Location: Australia, Melbourne
- Contact:
You can run DataStage jobs from other scheduling tools. The command for running a job is:
dsjob -run -param paramname=paramvalue -param paramname=paramvalue jobname
Setting parameters is optional. Another way is to schedule the job to run once a month and in the job control code exit straight away if the month is not Feb, May, Aug or Nov.
I believe that when you make a delivery from the Version Control tool you update the Version history for that object, which means you need write access to the Version project.
Vincent McBurney
Data Integration Services
www.intramatix.com
dsjob -run -param paramname=paramvalue -param paramname=paramvalue jobname
Setting parameters is optional. Another way is to schedule the job to run once a month and in the job control code exit straight away if the month is not Feb, May, Aug or Nov.
I believe that when you make a delivery from the Version Control tool you update the Version history for that object, which means you need write access to the Version project.
Vincent McBurney
Data Integration Services
www.intramatix.com
On the subject of your last question, keep in mind the fact that Version Control is not really a SCCS product. There is no such thing as "checking out" versions, deltas are not stored, no code branches, yada yada yada.
What it is is a methodology to allow the storage and retrieval of previous versions of jobs, and these versions are stored in their entirety in a special Project. Typically, work is done in a development project and, when ready, 'promoted' into Version Control and stored in the VERSION project. From there the code is moved into any other project, typically VERSION -> test and then VERSION -> production if all goes well. It tracks your changes and promotion history, handles 'batches' of jobs and can set the source code to read-only in your non-development projects. If you need to, you can pull older versions out of the Version Control project and 'promote' them back into test or production or all the way back into development, whichever is most appropriate.
All that being said, I for one really wouldn't want to go back to the days of 'releasing' jobs and using the Packaging Wizard to move them from project to project. We have a small group and only two of us have VC installed, but with it installed you have full access to it's capabilities. If you truly need 'check in/out' capabilities, you'll have to look elsewhere. If you don't, then (IMHO) you'll find it very useful. [:)]
-craig
What it is is a methodology to allow the storage and retrieval of previous versions of jobs, and these versions are stored in their entirety in a special Project. Typically, work is done in a development project and, when ready, 'promoted' into Version Control and stored in the VERSION project. From there the code is moved into any other project, typically VERSION -> test and then VERSION -> production if all goes well. It tracks your changes and promotion history, handles 'batches' of jobs and can set the source code to read-only in your non-development projects. If you need to, you can pull older versions out of the Version Control project and 'promote' them back into test or production or all the way back into development, whichever is most appropriate.
All that being said, I for one really wouldn't want to go back to the days of 'releasing' jobs and using the Packaging Wizard to move them from project to project. We have a small group and only two of us have VC installed, but with it installed you have full access to it's capabilities. If you truly need 'check in/out' capabilities, you'll have to look elsewhere. If you don't, then (IMHO) you'll find it very useful. [:)]
-craig
I agree with what has been said, and the fact that it keeps 'versions' of jobs it has some "Checkout" capabilities that once a job has been developed it is moved into the Version project. From there a copy is put into production. Where the checkout comes in is that what was developed in the Test project can be deleted and if it needs to be modified again the job can be "checked" out of the Version project back into the development project to be worked on. Please let me know if my train of thought is incorrect.
Thanks,
JB
Thanks,
JB
The reason I mentioned 'check out' capabilities is that usually means alot more than how you are applying it to VC. Yes, you can pull old versions out of VC, which can come in very handy.
However, in a SCC environment (from what I recall anyways) there is no copy of a job in development once it has been 'checked in', it only exists in the SCC system and possibly qa/prod. When someone needs to work on a job, it is checked out of the SCC system (typically local just to the developer), which then locks it so no-one else can check it out as well, and it remains that way until the job is checked back in.
This doesn't really jive well with the DataStage paradigm, even though certain aspects would be useful. I *suppose* you could emulate some of this by deleting things after promoting them, but that seems like a PITA to me.
-craig
However, in a SCC environment (from what I recall anyways) there is no copy of a job in development once it has been 'checked in', it only exists in the SCC system and possibly qa/prod. When someone needs to work on a job, it is checked out of the SCC system (typically local just to the developer), which then locks it so no-one else can check it out as well, and it remains that way until the job is checked back in.
This doesn't really jive well with the DataStage paradigm, even though certain aspects would be useful. I *suppose* you could emulate some of this by deleting things after promoting them, but that seems like a PITA to me.
-craig