Aloha: v5.235 error on surepos only

[Siriuslea]

Hi we have 2 terminals 1 IBM surepos and one PC clone. After about 3 hrs the surepos errors out with a page fault mainly when you try to open a new table, the debout is as follows. I think its crashing with any reference to terminal 0 table lock as we don't have a terminal 0.

Anyone have any ideas how to fix this?

Dec 08, 12:36:40 Ignoring file on server with long filename: Z:\Aloha\BIN\CalcEditField.tlb
Dec 08, 12:36:40 Ignoring file on server with long filename: Z:\Aloha\BIN\UserTools.tlb
Dec 08, 12:36:40 FileMatch: Z:\Aloha\BIN\PnlEdTS.GID len 10837, C:\Aloha\BIN\PnlEdTS.GID has len -1
Dec 08, 12:36:40 FileMatch: Z:\Aloha\BIN\PnlEdTS.GID time 29549158:-789304064, C:\Aloha\BIN\PnlEdTS.GID time 0:0
Dec 08, 12:36:40 (Diff = 29549158:-789304064)
Dec 08, 12:36:40 Master terminal re-connected to 'ALOHABOH' OK
Dec 08, 12:36:40 Found fileserver. Updating DOWNTIME.INI...
Dec 08, 12:36:40 Delete MultiSync flag 'C:\Aloha\DATA\MSYNC'
Dec 08, 12:36:40 Beginning synchronize data...
Dec 08, 12:36:40 Iberdir: Z:\Aloha Localdir: C:\Aloha Target: C:\Aloha\DATA
Dec 08, 12:36:41 SYNC: Copied Z:\Aloha\DATA\TRANS.LOG to C:\Aloha\DATA\TRANS.LOG
Dec 08, 12:36:42 SYNC: Copied Z:\Aloha\DATA\MIRROR.LOG to C:\Aloha\DATA\MIRROR.LOG
Dec 08, 12:36:42 SYNC: Copied Z:\Aloha\DATA\PRT3.LOG to C:\Aloha\DATA\PRT3.LOG
Dec 08, 12:36:42 SYNC: Copied Z:\Aloha\DATA\PRT1.LOG to C:\Aloha\DATA\PRT1.LOG
Dec 08, 12:36:42 SYNC: Copied Z:\Aloha\DATA\PRT2.LOG to C:\Aloha\DATA\PRT2.LOG
Dec 08, 12:36:46 End synchronize data (total 1074 files)...
Dec 08, 12:36:46 Synchronize Data Local DOB is 12/8/2005 in C:\Aloha\DATA\ALOHA.INI (12 08 2005)
Dec 08, 12:36:46 NOT USING COOL INTERFACE:Wave. Scheme's X resolution is 640. AlohaXRes environment overide is 800.
Dec 08, 12:36:46 Begin reading data...
Dec 08, 12:36:50 Check For Unregistered applications...
Dec 08, 12:36:50 ConvertTransLog(): Analysing TRANS.LOG for conversion...
Dec 08, 12:36:50 Iber(): No log conversion required.
Dec 08, 12:36:50 Done reading data.
Dec 08, 12:36:51 find_item: couldn't find item number 561974!
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 32
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 22
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 66
Dec 08, 12:36:51 find_item: couldn't find item number 55345!
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 30
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 28
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 60
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 38
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 42
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 70
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 64
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 48
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 58
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 50
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 26
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 56
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 46
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 44
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 68
Dec 08, 12:36:51 find_item: couldn't find item number 561085!
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 52
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 34
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 72
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 20
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 40
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 62
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 36
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 24
Dec 08, 12:36:51 firing 00:00:00 SET AUTOMENU 54
Dec 08, 12:36:51 firing 06:00:00 SET CASHIER MENU 1
Dec 08, 12:36:51 firing 06:00:00 SET SERVER MENU 1
Dec 08, 12:36:51 Begin reading transaction log...
Dec 08, 12:36:51 Done reading transaction log.
Dec 08, 12:36:52 OPOS Line Display Code Page could not be set to 999
Dec 08, 12:36:52 OPOS Line Display Current Code Page is 437
Dec 08, 12:36:52 OPOS Line Display Valid Code Page values are '437,897,858,852,855,857,862,863,864,865,808,869.998'
Dec 08, 12:36:52 Node = 1 String = 'B'
Dec 08, 12:36:52 Node = 2 String = 'C'
Dec 08, 12:36:52 Begin reading printer logs...
Dec 08, 12:36:52 Printer 2 OK
Dec 08, 12:36:53 Done reading printer logs.
Dec 08, 12:36:53 Terminal up...
Dec 08, 12:50:47 Creating terminal status for 2
Dec 08, 12:51:18 LISTEN: CONNECTED TO NODE 2! (24)
Dec 08, 12:56:01 RECEIVE failure: node 2 code 0A command 95
Dec 08, 12:56:01 SEND: failed! retcode 0A
Dec 08, 12:56:01 HANGUP: return code 08
Dec 08, 12:56:50 LISTEN: CONNECTED TO NODE 2! (26)
Dec 08, 12:58:42 Employee Num 0 FAILED to lock tabledef_id 200 (t->number is 0) since it is currently locked on terminal 0
Dec 08, 12:58:42 //=====================================================
Dec 08, 12:58:42 Exception code: C0000005 ACCESS_VIOLATION
Dec 08, 12:58:42 Fault address: 007035A4 04:0000B5A4 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 Registers:
Dec 08, 12:58:42 EAX:00000000 EBX:FFFFFFFF ECX:00000158 EDX:00AAEF40 ESI:007F5BE8 EDI:007F5BE8
Dec 08, 12:58:42 CS:EIP:0167:007035A4
Dec 08, 12:58:42 SS:ESP:016F:00AAEDD4 EBP:00AAF340
Dec 08, 12:58:42 DS:016F ES:016F FS:1B7F GS:0000
Dec 08, 12:58:42 Flags:00010216
Dec 08, 12:58:42 version 5.235f
Dec 08, 12:58:42 Operating system is Windows 98 (BuildNumber 67766446, Platform 1, Version 4.10, A )
Dec 08, 12:58:42 Call stack:
Dec 08, 12:58:42 Address Frame Logical addr Module
Dec 08, 12:58:42 007035A4 00AAF340 0004:0000B5A4 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 00514CFC 00AAF370 0001:00113CFC C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 007093A1 00AAF3AC 0004:000113A1 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 005BE075 00AAF3C4 0001:001BD075 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 0043B7A3 00AAF7F0 0001:0003A7A3 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 0043BFA9 00AAFC28 0001:0003AFA9 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 0043A75C 00AAFC68 0001:0003975C C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 004E7142 00AAFD6C 0001:000E6142 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 004E7703 00AAFD88 0001:000E6703 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 006C90B9 00AAFE38 0001:002C80B9 C:\ALOHA\BIN\IBER.EXE
Dec 08, 12:58:42 BFF8B560 00AAFF78 0002:00012560 C:\WINDOWS\SYSTEM\KERNEL32.DLL
Dec 08, 12:58:42 BFF8B412 00AAFFF4 0002:00012412 C:\WINDOWS\SYSTEM\KERNEL32.DLL
Dec 08, 12:58:42 Begin looping through registered threads...
Dec 08, 12:58:42 End looping through registered threads.
Dec 08, 12:58:42

 

[DTSMAN]

Anytime a terminal fails at posistion 0 it is a date and time issue.

Bo

Kentucky phone support-
"Mash the Kentrol key and hit scape."

 

[DTSMAN]

I may have responded to quickly, this may be a problem with LCK and OLK files in the Data folder. Delete those and see what happens.

The other scenario I mentioned happens when Aloha is loading.

Bo

Kentucky phone support-
"Mash the Kentrol key and hit scape."

 

[Siriuslea]

Thanks Bo, for the pointer. I was wondering where the lock files where kept.

Siri

 

[Siriuslea]

Hmm, I looked for the files you describe and couldn't find them in DATA or even the Aloha folder. Are they called something else in v5.2?

Siri

 

[AkamaiAloha]

No, they've always been called that. But I ran to this problem once myself, and I think I might have a solution for you.

The lock files (in this case, the OLK or order lock files) are dropped on the back of house DATA directory to prevent another user from trying to update the same record at the same time. Here's what happens... when the server opens a check, Aloha puts a flag file in DATA, the name of which is comprised of the terminal name and the check number on that terminal for that day (pretty sure thats what it is). So, if it was term1 and this was the 70th check for that day, the number would be something like 100070. This file... 100070.olk, is present when the table is open... and thus no one else can access when it's there. When the not in use, Aloha deletes the file from DATA (on the back of house) so someone else may access it. This process goes on all day long, with every check.


"Locking the database" as this is called, is standard practice with just about any database. However, with one particular customer, some how or another one of these files ended up on the front of house. How it got there, I don't know--the customer had been having some problems at the time, and it's possible someone copied the DATA from the front to the back while the a particular ticket was open. Anyway, because Aloha doesn't check the data directory on the Front of house during this process, it would never delete this file. Yet at the same time, when you reached that check number for the day (70th check on term 1), it would cause the terminal to crash everytime it was accessed. The part that made it difficult to troubleshoot is that some days they didn't open that any checks, and it made it seem inconsistent. Further more, all it did was perform an illegal operation, which happens with a wide array of problems with ALoha. So it was vague.

Anyway, sorry for the long explanation. But I bet you find the .OLK files on the one of the front of house terminals.

 

[Siriuslea]

AkamaiAloha and Bo, you are geniuses. That worked perfectly. There was an old .olk on the BOH that was left over from a few days ago. It was zerok and there was nothing in it. We deleted it and voila! it worked. The servers also thank you as loosing one terminal was driving them nuts.

Thanks again,

Siri

(anytime you are in Toronto drop by Tequila Bookworm for coffee)