Grab our RSS feeds Follow us on Twitter Join our Facebook Group Connect with us on LinkedIn
myITforum.com, Powered by You.
you are not logged in

Articles

Newslinks

Links

Downloads

Site Services

Community Forums

Discussion Lists

Article Search

Newsletter

Web Blogs

FAQs

Live Support

myITforum TV

Take a Poll

Monthly Drawing

myITforum Network

User Group Directory

Our Partners

About Us

Register

Login

BRONZE PARTNER:

BRONZE PARTNER:



Industry News:




  Home : Articles : SMS 2.x print | email | | Forums |   print | email | | Blogs |   print | email | | Wiki |   print | email | | FAQs |   print | email | Article Search  
Crashed SMSEXEC won't restart scheduled jobs.


Bookmark and Share

By: Donnie Taylor
Posted On: 6/26/2002

After an unexpected shutdown of the SMSExec service (via machine crashing or forceful shutdown of the service) incorrect files in the \SMS\inboxes\schedule.box\UID folder can stop or inhibit communications. Should you find this happening to you, here's what you can do.

Stop the SMS Executive Service.
Verify that the \SMS\inboxes\schedule.box\UID folder exists. Create it if it does not.
Place two files in this folder. Because the scheduler processes jobs in a sequential fashion, you will want to create files that are at the end of the processing cycle. Name the first one ZZZZZZZZ.JOB and the other ZZZZZZZZ.REQ. Make sure there are 8 "Z"'s in the file name.
Start the SMS Executive Service.
Monitor the UID folder for those file names to change. SMS will automatically rename them to the appropriate file names after processing has once again commenced. Of course how long that period of time is depends on factors such as hierarchy size and site server specs. Typically it should change those file names within a few minutes.

If you find that communications is stopped, but there are two files already in the UID directory, delete them before adding the "Z" files. More that 2 files in this directory can cause confusion in the SMSExec service.

Questions and comments welcome.

  myITforum.com ©2010 | Legal | Privacy