batch job run times

Finance and Operations/AX Developer Forum
1

Hi,

I’m facing another problem with a batch server (AX 4.0.2501.116) . After restarting it, batch jobs change their start dates and times to the date and time of the batch server restart. I’m not sure if it’s an intended functionality of AX or is it a bug, I’ve tried to change that, I’ve spent 3 hours searching for the code responsible for such an action (mostly in BatchRun class) but I can’t find anything that would point directly to the change of the date and time after server restarting. I think I’ll deal with it by creating another batch job that will set proper dates and times to other batch jobs, but I would like to know if anybody has faced such a problem and how was it handled. If somebody knows a more “proper” method to handle this, maybe a code modification, MS hotfix or config modyfication.

2

Hi,

I did some work on batch related area a while back. If I remember correctly, ‘prompt’ method in ‘RunBaseBatch’ class would call ‘doBatch’ method in ‘BatchInfo’ class. This is where records get inserted into ‘Batch’ table.

I have not seen the issue that you mentioned. Please make sure that there are no customisations on Batch related classes or tables.

Regards,

3

I’ve made another batch-job that - while running on batch server - should fix the run times of other batch-jobs. It works while running it manually, though it doesn’t run correctly on batch server (somehow - I have no idea why - it doesn’t execute itself, the batch server just ignores this job, doesn’t change it’s batch.starttime value as it normally should and there’s no sign of influence on other batch jobs). Any idea why? Here’s the source for the run() method, ran by main(), no other modifications attached.

public void run()
{
Batch batch;
int tempTime;
int interval;
Transdate tempDate;
container recurrenceDataChanged;

;

super();

ttsbegin;
while select forupdate batch
where batch.ClassNum != classNum(MPBatchDateTimeCorrection) &&
batch.Status == BatchStatus::Waiting
{
tempTime = batch.OrigStartTime;
tempDate = batch.OrigStartDate;
recurrenceDataChanged = [conpeek(batch.recurrenceData, 1),
batch.OrigStartTime,
batch.OrigStartDate,
conpeek(batch.recurrenceData, 4),
conpeek(batch.recurrenceData, 5),
conpeek(batch.recurrenceData, 6),
conpeek(batch.recurrenceData, 7),
conpeek(batch.recurrenceData, 8)];

while (tempDate < SystemDateGet())
{
[tempDate, tempTime] = SysRecurrence::next(recurrenceDataChanged, tempDate, tempTime);
}
if (tempTime < timeNow())
{
while (tempTime <= timeNow() && tempDate == SystemDateGet())
{
[tempDate, tempTime] = SysRecurrence::next(recurrenceDataChanged, tempDate, tempTime);
}
}

recurrenceDataChanged = [conpeek(batch.recurrenceData, 1),
tempTime,
tempDate,
conpeek(batch.recurrenceData, 4),
conpeek(batch.recurrenceData, 5),
conpeek(batch.recurrenceData, 6),
conpeek(batch.recurrenceData, 7),
conpeek(batch.recurrenceData, 8)];
batch.recurrenceData = recurrenceDataChanged;
batch.StartTime = tempTime;
batch.StartDate = tempDate;
batch.update();

}
ttscommit;
}

4

I’ve tested the job above in a local virtual machine and it works fine. I’ve noticed that the thing I’ve described (loosing track of runtime hours) might be connected with the fact that our client’s batch server isn’t configured in the usual way - it’s located in a separate (test) instance and connected to the production instance by a dedicated port. It works fine with most of the batch jobs, but some cause problems that aren’t present when running a batch client in the same instance the jobs are run. I’m still making research on why is that so. I’ll post the details when I find out what the problem is.