Aloha failed to grind last night 1

[cgdiaz]

Hello,

It seems like Aloha for whatever reason did not completely grind, when I got to the location all registers were at the Aloha screen waiting for the date to finish grinding. I was not sure how to fix the issue, so I took the whole directory out of the drive, restarted the registers, and they booted fine.

I really want to know why it failed to grind last night, and what steps I can take to make sure it goes back to being an automatic process.

I've been reading around the forums and saw many solutions, I attempted a few, but nothing that would take the systems down as I had customers. I will be going back tomorrow morning to try more things and also to see if it will fail to grind, or if it was only something wrong with the previous date.

I took the file that ends in .xxx, and put it in the directory for last night, in order to see if I could get it to grind the current day sales, and it would hang on the screen that says "grinding". Also, when I look for yesterdays sales, it shows me zero dollars. Any help would be greatly appreciated, attached is the debout file.

 

[dauphin2]

Doesn't show much other then the "WARNING: Couldn't find category 91". I would guess from this alone that grind is trying to reference something in the trans.log that does not correspond to the database correctly. It appears on many of the days that grind just times out or EOD stops it, but either way grind never fully finishes the "grind" process. You might need to run a grind with the debug switch to get some more information on the problem. Run "d:\Aloha\bin\grind /debug /date 20120831" from the aloha folder. You also might want to verify data and check the verify.txt for issues, it could just be a missing category.

 

[cgdiaz]

Hey dauphin2,

Thanks for the reply. I verified data, came up with no errors. Last night I also looked for category 91, but there was nothing there. I created a category 91 and just named it temp, to see if that would fix it but I'm having the same problem.

I restarted the system just now and it looks like I ran into some sort of VBO install? I tried to grab a screnshot but it went into a restart, will try again right now if it comes up.

No grind with debug yet, will do that next.

 

[cgdiaz]

Also, for some reason now my registers were showing an hour behind when I got here, they are fine now.

The computer restarted but I haven't encountered that VBO install again, from what I saw on screen it was a failed install/update.

 

[cgdiaz]

I found the VBO log, and it was definitely a failed upgrade but from the looks of the log this has been happening for a long time and doesn't really explain the no grinding. For the curious it was trying to install version 11.1.3.134. "The setup program failed to install a prerequisite, the software cannot be installed without the prerequisites. The installation process has been cancelled."

I'm in D:\Aloha and ran the command, "D:\Aloha\bin\grind /debug /date 20120830", my terminal shows no information, does it go to a file? If so, where does it go?

Oh and in case anyone needs it, I'm on Aloha TableService Version 6.4.20

I've been able to keep the owner happy since the registers are up, but I can't get the Sales Summary, FOH Cash Owed Report or Voids, I'm guessing the information is being stored properly and is just unavailable because the grind program hasn't put it together for me, am I right in this? Is there another way I can get the information for the owner?

Thanks again, hope this isn't considered spamming my own thread.

 

[dauphin2]

D:\Aloha\bin\grind /debug /date 20120830 would have to be run from the command prompt and will generate additional information in the debout.g01 file. You would go to the Windows command prompt, type "cd /d d:\aloha" and press enter. You would then enter the command "D:\Aloha\bin\grind /debug /date 20120830" or "D:\Aloha\bin\grind /debug /date 20120831" depending on which date you wish to analyze. Yes, you do not show any information because grind did not finish. If you post the entire 20120831 folder I could probably tell you whats wrong, but I would just not post it anywhere, as it will contain personal information for the employees at the restaurant. You can message me on alohapos for better security.

 

[cgdiaz]

Good Morning,

I'm not sure if it's through sheer luck or some sort of syntax thing, but I was finally able to get Aloha to manually grind. I did notice that the process that takes the longest is "Reading: transaction log", but it goes all the way through it. The program goes all the way through and my sales are finally available through the Aloha Manager.

I still don't know why it's not doing it automatically and for some reason my FOH terminals are not keeping time, since they are stuck since the morning and only boot up when I manually put the GNDBF30.xxx file in the dated directory.

Here are the end of day debout, and the debout from today when I finally got the three dated directories to grind.

https://www.dropbox.com/s/dzzywvq7hwpg30a/DEBOUT.g01

https://www.dropbox.com/s/a4sfua1fja2b3j6/DEBOUT.EOD

Any help would be greatly appreciated, thank you!

 

[dauphin2]

The grind process for 20120901 looks much cleaner then the grind for your previous days, so either the problem is fixed, or whatever was done on the previous days did not occur on 20120901. It could be a certain item, employee, tender, etc that causes the issue. At this point I would see if it reoccurs.

FYI, the offsets generated in the debout.g01 with the debug switch is what we use to track down the problem, so for the following we would examine what was actually going on between or around offsets 64639 and 64707

"Sep 02, 07:19:00, [3048], [INFO],,"grind: offset 64639 term 5 type 26 len 55"
Sep 02, 07:19:00, [3048], [INFO],,"WARNING: Couldn't find category 91"
Sep 02, 07:19:00, [3048], [INFO],,"WARNING: Couldn't find category 91"
Sep 02, 07:19:00, [3048], [INFO],,"WARNING: Couldn't find category 91"
Sep 02, 07:19:00, [3048], [INFO],,"WARNING: Couldn't find category 91"
Sep 02, 07:19:00, [3048], [INFO],,"grind: offset 64707 term 5 type 16 len 24

 

[cgdiaz]

I'm curious about this because I found the Category 91 error going back months, but the grind problem is completely recent.

I created a category 91, and named it temp, didn't add any items to it, but that was on the 31st, it still failed to grind the next day.

I'm hoping the owner has no more problems, but at the same time, I would much rather know what was wrong and be able to actually fix it!

 

[dauphin2]

That's the problem with Aloha. It could be something as simple as an antivrus program hanging up the grind process, CTLSVR not running under a user account, grind.exe still in memory from a previous failed attempt, etc.

 

[cgdiaz]

More Aloha woes,

The good news is, grinding works. Manually anyway. As far as I can tell, the problem is the EOD isn't running the grind process. I looked over the debout.eod and there was some error related to some log, both of which are posted below. I'm not sure where else to look for now, doing a little research and hopefully an answer comes out.

Any help would be appreciated, thanks!

Section that caught my attention

Sep 02, 04:00:10, [1448], [INFO],,"LogWriteTransaction - FileOpen failed: LastError(2)"
Sep 02, 04:00:10, [1448], [INFO],,"Creating Z:\Aloha\DATA\PRT4.LOG..."

Files:

debout.g01 seems to be clean -

https://www.dropbox.com/s/8cavvznjo7b2yjc/DEBOUT.g01

debout.eod -

https://www.dropbox.com/s/8t8znq944xuwu41/DEBOUT.EOD

prt4.log -

https://www.dropbox.com/s/u7wig7ca8tgs6hq/PRT4.LOG

 

[cgdiaz]

I have a theory on what might be happening but I'm not 100% sure. To me it appears that VBO is trying to upgrade, and the grind process is taking so long that when the VBO fails to update, and it restarts the computer, it interrupts my grind at night.

As a fail safe, I wrote a quick script that will re-do last nights grind since manual grinding is working, and it runs every morning at 5:30 AM, the file is here in case anyone is interested.

https://www.dropbox.com/s/yut82srgolzi90m/grind.bat

The majority of the code is getting the date right so the formatting is all correct when I send the grind command.

Here is a series of screen caps that I took when I forced an end of day early, leading me to my theory above.

https://www.dropbox.com/s/6qtrnchw8ej7x6i/VBO.jpg

https://www.dropbox.com/s/dtnpbyrdndw1fer/deltrack.jpg

https://www.dropbox.com/s/68hmmfab0hhun0m/shutdown.jpg

So I guess my question is now, does my theory sound probable? And, to add to that, what would cause my grind to take longer than usual? I'm thinking that maybe it's because in my Aloha data folder I have sales going back a few years, if I archive these somewhere else would that speed things up? Lastly, this location had a gift card thing at some point, but they don't do them any longer, can I remove VBO and not even have to deal with it anymore?

Thanks to dauphin for your continued help and anyone else that may be reading through the thread.

 

[dauphin2]

If they don't have gift cards anymore, then yes go ahead and delete any VBO components. I think the related services are Aloha Durable Messaging service, Aloha Enterprise Redirector service, and Aloha GC Legacy service. Also change GIFTCARDSALES_USE_GIFTCARD=TRUE to GIFTCARDSALES_USE_GIFTCARD=FALSE in the aloha.ini in the NEWDATA folder and run a refresh to disable gift cards within Aloha. The alohas.exe running in your processes is one of those services. If the system is rebooting before EOD is finished, then it definitely can be an issue. I know on the terminals they use taskkill.exe within the BIN folder to shutdown iber. You can remove that from the BIN folder on the terminals and server. Check the aloha.ini for the WINHOOK= and that will tell you the EOD batch file used. This will also be in the BIN folder.

 

[cgdiaz]

I know the .bat file is only a patch, but the owner is considering the issue resolved since at time of open everything is gravy.

If I get a chance to do anything more specific to this issue, I will update accordingly. Thanks again dauphin2.