DSXchange

Folks;
this is not an issue but in my learning process; I have this doubt..

We can create a sequenser using BASIC job control or the sequencer GUI in sequencer jobs..
What are pros and cons of the two methods?
I had observed that most of DS gurus do it in BASIC job control; When we can implement the same functionaly so simle by drag and drop why we should go to complex way of coding, There should defenetly some reason which I am not awre off, other wise gurus wouldn't be doing this, could come please little time to through some light on this for me..
thanks a ton in advance

Many of the gurus do it in job control code because we're still around from the days before job sequences, when it was the only way. Job sequences were quite limited when they first appeared, but now (7.5) seem to have most, if not all, of the constructs necessary, so most of us are coming around to not being quite so cynical about job sequences. It will always be the case that the generated code can't do absolutely everything you might want to do, but I would have to say it can now do most of them. I haven't written any serious job control code in over a year.

I agree with Ray.

Also in the sequencer, you need to add a new stage for each action whereas in Job Control you can achieve the same with one or two lines of code.

The biggest difference nowadays with the BASIC job control code that we use is it does... well, 'process parallelism' for lack of a better term.

From a list of jobs and their dependant predecessors, it will (if at all possible) keep X of them running at the same time - with X being a job parameter.

I think Craig has a valid point. I prefer sequences because it is easier to maintain after I am gone. I think Hester, Ken Bland and others have similar methods as Craig because it gives them control. They have had restart capabilities for a long time because of this. At some point maybe they need to switch over to sequences. When do they do that. At what point is it better for the customer to have something that is more mainstream and maybe simplier and easier to understand.

Hester's and Bland's batch control solutions are very complex and very powerful. The sites seem to run smooth that use these methods. There is a trade off between complexity and being able to modify and understand the solution. There also is a relationship between talent and complexity. If your company chooses inexpensive less experieced talent then you want a solution which is simple and easy to understand. If your company wants things to run smooth and is willing to pay for the best talent then they can and need more complex solutions.

There is a place for each solution based on customer need. The problem is when a consultant thinks his solution is the only one and all of us should do it their way. Look out. This consultant will cause problems somewhere down the line. Sometimes re-engineering an existing solution costs a lot more than it saves in down time.

For the record, we are using a modified version of Ken Bland's KBA Job Control Utilities. As noted - very powerful, and I'm not sure how we'd ever replicate some of the functionality in a Sequencer.

For example, I just recently added a new methodology to exit from a running batch stream with all running jobs left intact. Problems with individual jobs can be corrected and the job stream then 'rejoined' midstream, picking up where it left off dynamically.