RE: Dividing jobs to diffrent job queue depending of job type

Hi Albert

This concept just struck me as "print distribution" for jobs.

As for the right place to determine the target job queue being the source I
couldn't disagree with you more. Job Description, User profile, Routing
Entry - anywhere but hardcoded into the source in my opinion. Just means
something as basic as routing to another job queue requires recompilation.

I understand about the surprise but I think that would happen once and if
you know the rules it makes everything much simpler - every program' SBMJOB
is the same, a much nicer situation.

I think the command exit is an overly complicated solution - the job
notification exit point strikes me as easily the best solution.

An added benefit of this is that you can tell the "job marshalling" program
to sleep during the backup or any other production blackouts - effectively
halting the submission of jobs to production queues - in a much simpler and
command driven way than an exit point approach would allow.


Regards
Evan Harris


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Albert York
Sent: Friday, 7 August 2009 5:45 a.m.
To: Midrange Systems Technical Discussion
Subject: Re: Dividing jobs to diffrent job queue depending of job type

Well, when you factor in the potential harm that can come from messing with
the job submission mechanism on the AS/400 plus the requirement that the
solution is completely documented and understood so that it can be supported
if the author is not available and the effort involved in every PTF and
upgrade it seems simpler to me. A few hours of search and replace.

I know that I would find it confusing if I submitted a job to a job queue
and it popped up somewhere else, simply because i used the wrong name.

It also places the decision making at the source, where it truly belongs.

But maybe I'm overthinking the whole thing.

Albert