Re: got bitten by RTVJOBA date

On 19 Jul 2013 13:58, dale janus wrote:

I often use RTVJOBA in CL to get user name and system date. I know
it's the job date <<SNIP>>

I have some month end inventory processing that I run on the last day
of the month. It manipulates the dates so I can get the month, the
month from 2 years ago and from 3 years ago and date stuff we've all
done lots of times.

I had a home grown CL where I would put in 1 year's worth of dates
and run if it was the 25th.

So I got 'smart' and set it up as a scheduled job last December. It
has been running like clockwork at 10pm the 25th of each month (our
month end). What I did not realize was the job is set as the day I
put in on the schedule, not the day it runs. So for the last 6
months, I was re-running December 25th 2012 over and over. (I'm not
even sure how it got 12/25/12 as the date submitted. No one around
here works on Christmas)

The request to effect scheduling the job should be run monthly on the 25th of each month would have been a request to ADDJOBSCDE SCDDATE(12/25/12) FRQ(*MONTHLY), for which that first run in December of 2012 would have been the 25th, and every repeating request starting on the 25th of each successive month [at the same scheduled time]. That request could have been made anytime before that date.

I use the month number as part of the file name, so my FILENAME12
stuff got overlayed every month.

I have now changed those jobs to RTVSYSVAL QDATE.

I do not recall what QMONTH returns, but that might be simpler, if the code can safely assume its run is appropriate for the month. If the actual numeric day portion of the date is tested for the 25th, then not using the job date, having switched to using QDATE, makes any attempt at recovery performed later in the same month more difficult [without changing the code].

FWiW: In the event that QTIME might also be desirable within a CLP which retrieves the system value QDATE, I [since it became available] prefer to get the QDATETIME system value instead; i.e. the time and date are retrieve in one request to avoid two requests spanning a day if the requests are made near midnight.

I'm sure I read somewhere, sometime, a long time ago, that scheduled
jobs use the job date when added to the schedule, not the date run.
But I forgot about it.

That seems odd. I thought the scheduler picked up the information from the JOBD() for the scheduled entry much like SBMJOB DATE(*JOBD) from a command line. Is it possible that the Job Description object for the user profile defined to run the submitted job, was modified [perhaps just for testing] to have the date 2012-12-25?

Less likely is that the command added to the scheduler was a SBMJOB request whereby either the DATE(12/25/12) was specified or derived from the Job Description for that separate submit request.

Now I've got to see what I can clean up and how far back our backups go.
I just wanted to share my sad tale as I go off to cry in my beer. Lots
of beer.

Mmmm... Beer.