Preventing Aloha from kicking of a scheduled grind

[rrgsti]

Hi there,

Is there a way to prevent scheduled current day grinds from running if I start one manually (to regrind a previous day for example). It seems that if two are running at the same time, they get wrapped up and the process hangs indefinitely.

Thanks

Bob

 

[AlohaRoss]

Bob are you using the Aloha pulse app? Usually the pulse app does its grind every 5 minutes to update the pulse mobile app. You can stop the aloha ftp service. Grind what needs to be grinded and then restart the ftp service. See if that works for you.

AlohaRoss

http://www.needalohahelp.com

 

[MenulinkMan]

Insight CDP does the same thing. Possibly try running NET STOP POLLCHECK

 

[SwampGas]

CDP polling for Insight should not be scheduled to run more than once an hour max. It is preferred to have CDP run by day part or every 4 hours for CDP.

If you are getting grind processes having issues, then there is a different problem on your POS. The grind process is not gracefully exiting every time and you should start by reviewing the log files to see if you can determine why. The process is designed to handle simultaneous calls without issue. So, when you are having the issue, then that is an indication of another problem.

 

[rrgsti]

Hi Folks,

Thanks for the responses, and I apologize for the typo in the title. That drives me nuts.

I honestly don't know much about Aloha in this instance, I'm just writing up a small utility to do dated folder regrinds on command. I was just told (and seem to have observed) that if multiple instances of grindq are operating at the same time, they can get stuck. If it's possible for Aloha (QS?) to run a grind for today's date while I run one for a dated folder, then maybe it's not a big issue. I just saw at least one instance where it seemed to get into a loop and we had to rename the dated folder before it would stop (rebooting didn't help).

Sounds like there isn't a way to stop it except for possibly stopping the ftp and/or pollcheck service...I'll take a look at those approaches.

Thanks!

Bob

 

[SwampGas]

The best way to do dated subdirectory regrinds is to just delete the gnddbf30.xxx file in each dated directory. The POS will grind each directory safely. Calling the grind command manually each time for that is not the recommeneded method. Then have you application wait for the grind process to not exist for a few seconds before continuing.

What you are describing is not an issue unless there is other problems on the POS. You will always hear the, "One off", story from someone, but the process is sound.

 

[SwampGas]

Also, if a .XXX file exists in the dated subdirectory you should not need to be re-grinded unless there is an update to adjtime.dbf. The .XXX file is a semaphore to let the grind process know not to grind that directory again because it is already current.

 

[rrgsti]

Thanks for the additional information, much appreciated!