But what if a simple critical operation needs to be run monthly on the first or second weekend of the month? This task presents a dilemma for the staff assigned to execute it. Whether it be executed from a job entry setup by a programmer or activated from a menu option by an operator, it has this one undesirable requirement: Somebody has to remember to execute it at the appropriate date and time. This equates to an operational time bomb because humans are fallible. Sooner or later, someone will forget.
A solution to this dilemma is to take out the human factor and let a machine (the AS/400 or iSeries) handle it. This boils down to setting up two scheduled jobs. The first job is the "client" program. This is the critical task that needs to be run monthly at a variable date. The second job is the "manager" program. This program is submitted on a fixed date, takes charge of determining the next execution date of the "client" job, and makes the appropriate changes to the client's schedule.
For example, assume that the current month is August and that starting in September there is a program that needs to be run on the second Sunday of every month. Following is the sequence of activities to implement this solution:
1. Decide on the names for the client and manager scheduled jobs. It is important to make them as similar as possible so they will appear together in the WRKJOBSCDE display and visually make their relationship readily apparent, like so:
- Client Job Name--MYJOB_RUN
- Manager Job Name--MYJOB_MGR
2. Decide on the next execution date for the manager program. This is somewhat arbitrary. Since MYJOB_RUN needs to be run on the 2nd Sunday of the month, that means the MYJOB_MGR may run on any of the first seven days of the month and still be early enough to set the next execution date of MYJOB_RUN. In this case, the fourth day is quite suitable.
3. Create a scheduled job entry for the client program (the critical task) and set this task to run at a distant future date.
- Job Name--MYJOB_RUN
- Frequency--Once
- Recovery Action--*SBMRLS
- Save--*YES
- Command--Call to whatever program needs to be run
- Date--Initially set to some distant future date like "12/22/05".
4. Create another scheduled job entry for a "manager" program. The manager program replaces the programmer in updating the variable execution date.
- Job Name--MYJOB_MGR
- Frequency--Monthly
- Recovery Action--*SBMRLS
- Command--Call to program MYJOB_MGR
- Date--"09/04/02"
5. Code the MYJOB_MGR program to compute the next execution date of the client program and update the client program's scheduled job entry MYJOB_RUN.
The process is relatively simple:
1. September Cycle:
- On September 4, the MYJOB_MGR manager job is submitted.
- The MYJOB_MGR program computes the next execution date for the MYJOB_RUN client job (which should be 9/8/02) and then updates MYJOB_RUN's scheduled date.
- On September 8, MYJOB_RUN job is submitted, and its schedule entry goes to "SAV" status.
2. October Cycle:
- On October 4, the MYJOB_MGR manager job is submitted.
- The MYJOB_MGR program computes the next execution date for the MYJOB_RUN client job (which should be 10/13/02) and then updates MYJOB_RUN's scheduled date.
- Once MYJOB_RUN's schedule date is updated, it changes status from "SAV" to "SCD."
- On October 13, MYJOB_RUN job is submitted, and its schedule entry goes to "SAV" status.
3. The October Cycle is repeated for the succeeding months.
A sample CL program for MYJOB_MGR is shown below.
--Ricardo P. Ang
|
got tips?
Share your tips with your peers!
Get famous!
Get paid!
Send them to
LATEST COMMENTS
MC Press Online