The system scheduler has a special value for this: there is no date to calculate.
ADDJOBSCDE JOB(CLOSE) +
CMD(CALL PGM(PRODLIB/CLOSE)) +
FRQ(*MONTHLY) +
SCDDATE(*MONTHEND) +
SCDTIME(230000) +
JOBQ(QBATCH)
For the last working day, keep the schedule daily and put the check in the program: "working" depends on the company calendar.
Example: the last working day
This is the request that arrives right afterwards, and *MONTHEND does not cover it: the 31st
can fall on a Sunday, and the close has to run on the Friday.
There is no system value for it, because "working" depends on the company calendar: local holidays, shutdowns, bridge days. The schedule stays daily and the decision goes into the program, against a table the company almost always already has:
SELECT 1
FROM PRODLIB/CALENDAR
WHERE DAY_DATE = CURRENT DATE
AND WORKING = 'Y'
AND NOT EXISTS (
SELECT 1 FROM PRODLIB/CALENDAR
WHERE DAY_DATE > CURRENT DATE
AND WORKING = 'Y'
AND YEAR(DAY_DATE) = YEAR(CURRENT DATE)
AND MONTH(DAY_DATE) = MONTH(CURRENT DATE))
It reads like the definition itself: today is a working day, and after today there is no other one this month. If the query returns a row the program carries on, otherwise it exits.
The calendar table is the part that has to be built once and maintained. Whoever lacks one ends up coding this year's holidays into a program, and doing it again next year.
Tip
*MONTHEND handles February and thirty-day months on its own. Before it existed
people wrote scripts that calculated the date, and those scripts failed on every leap year.
Warning
SCDDATE and SCDTIME use system time. If daylight saving is not handled the
way you expect, a job scheduled at 23:00 can run an hour early or late twice a year: check
QUTCOFFSET and QTIMZON.
Releases. SCDDATE(*MONTHEND) predates every release currently in support: if the system
is on a supported release, it is there.
Comments
No comments yet. Be the first to comment!
You need an account to comment. Log in · Sign up