RE: executing jobs in sequence -- MIDRANGE-L

Michael,

I suppose a larger CL could be considered harder to maintain.  However,
I think it is easier to maintain the CL rather than the documentation
required to run all the steps individually.

In addition, you could always have a couple of layers of (CL or RPG)
programs.  Have a main NIGHTLYJOB program call for example, a program
than runs all the Ordering related steps.  Then the NIGHTLYJOB calls
another program that runs all the Inventory related steps.

HTH,

Charles Wilt
--
iSeries Systems Administrator / Developer
Mitsubishi Electric Automotive America
ph: 513-573-4343
fax: 513-398-1121

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx 
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Michael Rosinger
Sent: Monday, January 08, 2007 9:05 AM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: executing jobs in sequence

"Jones, John (US)" <John.Jones@xxxxxxxxxx> wrote in message 
news:mailman.42.1168262354.12056.midrange-l@xxxxxxxxxxxxxxx

A second option which would be more complex to develop but

potentially

nicer to use (depends on your job stream) would be to have

a single CL

program drive all of the batch work (either inline or via

SBMJOBs) and

have that CL program monitor for errors and enable whatever

corrective

measures you require.


Thanks for the suggestion. On the VSE system, all of these "jobs" are 
contained in a single library "book". There are a lot of them 
and it is 
easier to maintain this way. Are there any disadvantages to 
maintaining 
single large CL program for the entire run?

-- 
Regards,

Michael Rosinger
Systems Programmer / DBA
Computer Credit, Inc.
640 West Fourth Street
Winston-Salem, NC  27101
336-761-1524
m rosinger at cciws dot com

Building on this, if you need to re-run a job, the jobs in

the job queue

are prioritized.  So the re-run can be submitted to the

same queue but

at a higher priority to move it ahead of the others,

ensuring all jobs

run in the desired order.

The single-threaded job queue that Lukas mentions is a

great thing.  We

use them here for handling things that can only be done one

at a time

and for handling long-running batch jobs that would bog

down if too many

ran concurrently.



-- 
John A. Jones, CISSP
Americas Information Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
john.jones@xxxxxxxxxx

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Lukas Beeler
Sent: Monday, January 08, 2007 7:03 AM
To: Midrange Systems Technical Discussion
Subject: RE: executing jobs in sequence

Hi Michael,

You can do this with i5/OS Job Scheduling quite easily.

I would recommend you to read through the Job Scheduling

documentation,

as the Job Scheduling options of i5/OS are quite extensive (but
nonetheless easy to learn).

Your "steps" are obviously normal "jobs", when we're

talking about job

scheduling, so all you need to do is create a job queue

which limits the

concurrently running jobs to one (use CHGJOBQE, or better

yet, create a

new job with CRTJOBQ). You can view available commands with

GO CMDJOBQ.


You can hold a JOBQ using the command HLDJOBQ, which is the

same as what

you call "PAUSE". If a job has a problem, it usually falls to status
"MSGW", the message wait status. Depending on the Problem,

the operator

can fix it, and answer "R" retry to the message, and the job will
continue from where it left off. As an alternative, you can HLDJOBQ,
then "C" cancel the job, and resubmit the job to another

jobq (which is

not in hold status). After that, you can RLSJOBQ, releasing the job
queue again.

Job Queues are associated with a Subsystem (SBS), and resources are
allocated to individual subsystems, not the job queues themselves.

Hope this helps,

Lukas

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of

Michael Rosinger

Sent: Monday, January 08, 2007 1:07 PM
To: midrange-l@xxxxxxxxxxxx
Subject: executing jobs in sequence

List,

I am trying to get a feel for how best to duplicate some our nightly
batch job runs on the iSeries that run on our VSE system. I

am open to

ideas and suggestions. We would of course want the same

basic results

and control but realize things may have to be handled

differently simply

due to the differences between the two operating systems.

Here is a "brief" description of our current process....

The nightly batch run consists of many "jobs". They are,

for the most

part, single-threaded. We do not currently have scheduling

software on

VSE, so

this is operator-controlled. Each "job" will have one or

more "steps". A


"step" is an execution of an application program. After the jobs are
submitted, each with any required parameters, the jobs run

in sequence

with virtually no operator intervention required.

If a job fails, it requires an operator response which

prevents the jobs


behind it from running. Depending on the nature of the problem, the
operator can release a "PAUSE" in that batch partition to

keep the rest

of the jobs from executing while the failing job is re-run in a
different partition.

Then the "PAUSE" is release and the rest of the jobs

continue on their

merry way.

What is the best way to duplicate this batch process on the iSeries?

Will we need scheduling software to accomplish this?

Are the built-in iSeries scheduling capabilities sufficient?

TIA for any advice and/or ideas!

--
Regards,

Michael Rosinger
Systems Programmer / DBA
Computer Credit, Inc.
640 West Fourth Street
Winston-Salem, NC  27101
336-761-1524
m rosinger at cciws dot com


--
This is the Midrange Systems Technical Discussion

(MIDRANGE-L) mailing

list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting,

please take a

moment to review the archives at

http://archive.midrange.com/midrange-l.



-- 
This is the Midrange Systems Technical Discussion

(MIDRANGE-L) mailing

list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.


This email is for the use of the intended recipient(s)

only.  If you have

received this email in error, please notify the sender

immediately and

then delete it.  If you are not the intended recipient, you

must not keep,

use, disclose, copy or distribute this email without the

author's prior

permission.  We have taken precautions to minimize the risk of 
transmitting software viruses, but we advise you to carry

out your own

virus checks on any attachment to this message.  We cannot accept 
liability for any loss or damage caused by software viruses.  The 
information contained in this communication may be

confidential and may be

subject to the attorney-client privilege. If you are the intended 
recipient and you do not wish to receive similar electronic

messages from

us in the future then please respond to the sender to this effect.



-- 
This is the Midrange Systems Technical Discussion 
(MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.