RE: Day Start -- SYSTEM21

Jon is spot on... The 5:00 am time certain would cause the job to wait until tomorrow AM to run today's "late" request... So when you run the RUNADSJOB tomorrow you would get two jobs running at 5:00 AM... This theory assumes your day start is some time before 5:00 AM... But this also illustrates a diabolically more subtle problem...

It has always been my understanding that the RUNADSJOB is supposed to delete any previously launched copies of the JOBSCH job in QCTL whenever it runs... This would normally wipe out any jobs waiting in the job scheduler... If it is not deleting the old iteration of JOBSCH and restarting it then it is my humble opinion that something is wrong.

We had that problem a while ago and discovered that the way we were calling the RUNADSJOB command in ADE was wrong... We found that if we called the RUNADSJOB from a command line in the middle of the day it would work as I described above - Delete the current JOBSCH job and everything that was scheduled to run in the scheduler was wiped out. But when it ran at night in the ADE it would not behave "correctly". All the day jobs would run as normal but there was a hidden problem...

We eventually found that we were not Submitting the RUNADSJOB command when we launched it from ADE... What would happen is the OS/400 would eventually generate an error because the call stack would go "too deep" and another symptom would be extremely large job logs for the JOBSCH job (several thousand pages...!). This would usually take about 6 weeks to failure. (We only IPL a few times a year).

Look closely at your JOBSCH joblog for the current iteration. The jobs start date should be today... If it's not then you're calling the RUNADSJOB cmd "interactively from the ADE jobstream"... You need to SUBMIT it by specifying a job name on your MM ADE entry. If you call it "Interactively within the Scheduler job stream" it cannot delete the current copy of JOBSCH because it has a lock on itself... Kind of like a snake swallowing it's own tail...!!! But if you "Submit" the RUNADSJOB command it can then swallow the snake... Just as it does when you call RUNADSJOB from the command line in the middle of the day.

The call to RUNADSJOB in the ADE should look like this:
Sequence  . . . 1230 Update  Desc Run ADS Job

Job name . . . RUNADSJOB Blank for job to be run rather than submitted. <---***Important*** Job desc. . . . MMJOBSCH *LIBL Job queue . . . QTXTSRCH Job user . *CURRENT (*JOBD *CURRENT) Job priority . 5 Message queue . QSYSOPR (Message queue name or *NONE) Request data. . RUNADSJOB

Be sure you specify a job name to Submit it and not run it "Interactively within the Scheduler job stream"... This should be the second to last entry in the ADE list... The last entry should always be DLTADEOVR and you should never override this option not to run...

If you were not the original architect of your Machine Manager scheme you may be surprised to discover how it is really working... It can be challenging to wrap your head around what's really going on within MM even if you designed the schedule yourself...

I rely heavily on the MM and have many entries in ADS and ADE... I have to give careful consideration to where I place any new entries I might need to add... Do I run it in ADS or ADE... Run Immedate or delayed... If delayed, do I send it to a jobq that is on hold for later release or do I specify a time certain for the job to start... "Submit" it or run "Interactively within the Scheduler job stream"...

Some people I've talked to don't use MM simply because they don't understand how it works... Those people usually pefer the IBM scheduler... But there are so many powerful things you can do using MM... It's a great tool uniquely suited to running JBA tasks. The two major drawbacks are lack of Dependant Processing and the inability to easily schedule batch jobs with variable dates...

The point is you can make it simple or you can make it complicated... But in order to know what to do when something goes wrong it helps to understand what is really going on inside the scheduler...

Sorry for being so long winded... Hope that helps...

Good luck...

----Original Message Follows----
From: "Neil Thursby" <neil.thursby@xxxxxxxxxxxxxxxxxxxx>
Reply-To: System 21 Users <system21@xxxxxxxxxxxx>
To: "System 21 Users" <system21@xxxxxxxxxxxx>
Subject: RE: [SYSTEM21]   Day Start
Date: Thu, 11 Dec 2003 09:59:06 -0000

Jon, That sounds like a very good explanation; We have a mix of tasks in Day Start. "System tasks" like IBM & JBA subsystem starts are set at 99:99:99 whilst reports, reconciliations etc have a specified time. The idea was that we always want "system" tasks to run at Day Start but non-system tasks only at a specified time.

Having reviewed the logs, it could be that it was only the time-specific jobs that ran twice. I'll try your suggestion next time we have to IPL.

Thanks,

Neil.

-----Original Message-----
From: JonWadey@xxxxxxxxxxxxx [mailto:JonWadey@xxxxxxxxxxxxx]
Sent: Thursday 11 December 2003 09:56
To: System 21 Users
Subject: Re: [SYSTEM21] Day Start

Neil,

If you have your tasks set to specific times say 05:00.  When you did your
IPL and the system restarted it would have placed this task at status QS
(Queued Successfully) waiting for the time 05:00.This can be seen within
Machine Manager - Manage Scheduled Jobs.  When you then do your normal Day
End and Day Start this task is still waiting in the Queue and will be
joined by the job started by your new Day Start therefore it will run
twice.

We've encountered this problem before and now if I need to IPL the system
I always go into Managed Scheduled Jobs and delete any jobs before I IPL
the box and afterwards to get rid of unwanted queued tasks.

regards

Jon

Jon Wadey
IT Manager
M & S Toiletries Ltd
Tel :- (+44) 1506 835600
Fax :- (+44) 1506 835609

_________________________________________________________________ Don?t worry if your Inbox will max out while you are enjoying the holidays. Get MSN Extra Storage! http://join.msn.com/?PAGE=features/es