Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Aloha Item Count not working

Status
Not open for further replies.
Nov 1, 2005
178
US
I've seen run across this before, and I am not sure if this is documented, but I know some else has across it.

A customer a corrupt transaction log that was goofed beyond repair. The next day, all their ITEM AVAILABILITY entries were gone, poof, into thin air. I can see the item count *.cnt file in data, but they are no longer showing up on the FOH. Any ideas?

TIA,

AA
 
You may be missing some files from Newdata or Data. Compare those folders to one that works right. I do not know what you are missing.

I did find this bit of Aloha documentation.

"Item Availability can cause unpredictable results, deleting unused or superfluous
.CNT files will not have an adverse effect on the FOH since the tracking information is also stored in the
TRANS.LOG (transaction log)."


Bo

Kentucky phone support-
"Mash the Kentrol key and hit scape."
 
I am 90 percent sure that the corrupt trans log messed everything up. How messed up is the trans log? Radiant finally gave us dealers the utiliy to get into the file and manipulate it, so if you want, you can send it to me and I can take a look at it.

Adam
 
Thanks for offer Adam. The problem at this point seems to be that somewhere during the EOD process, the data in the trasaction log is getting deleted or wiped. When I got onsite to see the problem for myself the first time, the TRANS size was almost 0 Bytes. By that point, both a tech and the customer, who was assisting the tech over the phone, had their hands on it. So who knows what happened... I didn't give it much thought, since I was not the one on the phone, and it could have been anything.

However, it happened again a few days later. This time, EOD ran fine. But when they went to print their sales data, it was more or less empty. I dialed in (before anyone could mess with it), and it was the same deal.. very tiny transaction log (like 804 bytes). So, as you can see, this problem is much bigger than just the Item Count. There is something going wrong during EOD, and I will let you know/seek opinions when I have chance to look at it more. In the meantime, this customer is freaking out over the prospect of having to manually enter in all the employees again for payroll (and over losing their sales data).

Doesn't Aloha (5.236) usually back up the transaction log in the TMP? How do I go about finding it?

any suggestions are greatly appreicated.
 
The only backup of the trans log is the mirror log in the same folder. Untill you find out what's going on, I would suggest you create a batch file to copy the data folder to another location before eod runs. That way you have a copy of the original translog. What does the eod debug file say?

Adam
 
Thanks for your response Adam. The EOD has shed some light on the process, along with something else I noticed. It almost looks like the system is trying to run EOD twice in a row.

Dec 16, 04:00:26 Creating Z:\Aloha\DATA\TRANS.LOG...
Dec 16, 04:00:26 Creating C:\Aloha\DATA\TRANS.LOG...
Dec 16, 04:00:26 Creating Z:\Aloha\DATA\PRT2.LOG...
Dec 16, 04:00:26 Creating Z:\Aloha\DATA\PRT5.LOG...
Dec 16, 04:00:26 Checkpoint P: result 1
Dec 16, 04:00:26 Updating adjtime files...
Dec 16, 04:00:25 Commence rolling directory...
Dec 16, 04:00:25 Creating subdirectory Z:\Aloha\20051215
Dec 16, 04:00:25 Found txn log 'Z:\Aloha\20051215\TRANS.LOG' already in dated directory, backed up as 'Z:\Aloha\TMP\BACK0023.LOG'

In a nutshell, it's trying to copy the transaction over twice, or so it seems. I renamed the BACK0023.LOG to TRANS and reground it, and the customer said that it looks like all the data is there. Furthermore, when I went to grind 121505, it warned me the DOB was wrong--it was 121605. So, it's almost as if it tried to run 2 EOD's in a row using the same dated sub. Even weirder still, the DOB in DATA was accurate.

I seriously think this is an XP issue--I just get that feeling. But anyway, this is a summation of the facts:

-System is trying to copy the trans.log to the dated sub twice, resulting in a log file with no data, and original data backed up in TMP.

-EOD is only scheduled once in events, at 4am.

-Problem Does not happen every day. Problem is intermittent, happening twice in a week and a half since file server was replaced with one running XP.

-system restore is turned off in xp.

thats about all i can think of for now. i will post more theories or info when i get it.

thanks for all your help!

 
The problem related to this thread has not happened again, but I am not convinced that it won't. I have a feeling in my gut that is has something to do with XP being on the file server. Can anyone cover the major DO's and DON'Ts for the file server with XP? I had the Windows 2000 as file sever AKB, but the one for XP as file server is corrupt. Bo, if could post that, or someone could just rattle off the major points (for example, turning off system restore) that are specific only to XP, that would helpful. Essentially, just what is differnt with XP--I have done XP file servers before and not had problems, so just wanna double check here.

TIA
 
Summary
The ALOHA® application software requires you to configure the Microsoft® Windows® XP operating system (OS) to properly run on the run on the file server. Failure to properly configure Windows XP will result in erroneous Aloha application software behavior. If you are using the file server to run both Front-of-House (FOH) and Back-of-House (BOH) together, refer to document ID 6148.

Information
Although some computers come with Windows XP preloaded while others do not, this document is based on editing the settings of an existing Windows XP installation. Users who are installing Windows XP from scratch or upgrading another OS to Windows XP can still use this document either by employing these instructions after the Windows XP installation or by making some of these changes during the Windows XP installation.



In regards to the Aloha application software functionality, the only difference between Windows XP Home Edition and Windows XP Professional is the number of concurrent incoming user connections allowed by the OS. Windows XP Home Edition enables up to five connections and Windows XP Professional enables up to 10 connections. You cannot increase the number of connections. Breaking the connection limit may disrupt the Aloha application software. Refer to ID 6018 for more information the recommended number of FOH terminals for each operating system.

Drive Sizes and Partitions
Refer to document ID 6153 for more information on hard drive partitions and file systems.

Network
Set the workgroup name the same on all terminals and the file server. Aloha Technologies generally uses IBERTECH as the workgroup name, but this name is arbitrary as long as it is consistent throughout the Aloha application software.



You can configure Windows XP as a member of a workgroup or a domain. Select a workgroup name. Only experienced network administrators should consider enabling a domain name.



Aloha Technologies uses the network name ALOHABOH by default, but this name is arbitrary, so a different name can be used if desired.



Aloha Technologies prefers the use of static IP addresses (which are defined on the file server instead of dynamically assigned), but you can use dynamic addressing as long as you ensure that terminals always have an address assigned to them. The Aloha application software will not function without an IP address assigned to the terminal. You may have multiple protocols installed as long as the proper protocol for the Aloha application software has been marked as such by the lana number assignment. Assign lana number zero to the network binding (protocol and adaptor) used by the Aloha application software. Refer to document ID 5988 for more information on assigning lana numbers.



NetBIOS must be enabled over TCP/IP to use TCP/IP with the Aloha application software. To do this, access the TCP/IP properties for the Local Area Connection, click the Advanced button, and select the WINS tab. Select 'Enable NetBIOS over TCP/IP'.

TCP/IP Media Sense
Windows XP uses Media Sense with TCP/IP to determine whether the network card is in a link state. If the computer is removed from the network or the network becomes disabled, Media Sense disables TCP/IP, which can disrupt the Aloha application software.



Perform the following to disable Media Sense in the Windows Registry:



The incorrect use of Windows Registry Editor can lead to serious, system-wide problems that may require the reinstallation of the operating system. Use this tool at your own risk.



New registry entries described in this document are enclosed in quotation marks. Please ignore these quotation marks when adding the entry in the Windows Registry. All Registry entries are case sensitive.



1. To open the Windows Registry Editor, select Start/Run, type REGEDIT, and click OK.

2. Path out HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters.

3. Verify the DisableDHCPMediaSense value exists in the folder. If it does, double-click it and change Value Data to '1'. If it does not exist, choose Edit/New/DWORD Value and name the key ' DisableDHCPMediaSense '. Then double-click the entry and change Value Data to '1'.

4. Select Registry/Exit to exit the Windows Registry Editor.

5. Restart Windows.



Media Sense provides the ability to connect to networks with different DHCP options in one Windows session without the need to release and renew the IP configuration by using IPCONFIG.EXE. If you disable Media Sense, no new IP configuration information is obtained when you connect to a new network unless you restart the computer, or you release and renew the IP configuration by using IPCONFIG.EXE.



Refer to Microsoft Knowledge Base document Q239924 for more information on Media Sense.

File Sharing
The Aloha application software requires a network share labeled BOOTDRV that enables read and write capabilities to the Aloha application software file server and FOH terminals. This share needs to be applied to the root folder or drive in which the Aloha folder resides. If the Aloha application software resides in C:\ALOHA, share C:\ as BOOTDRV. If it resides in D:\ALOHA, share D:\ as BOOTDRV. If you created a special folder for the Aloha application software, share the special folder as BOOTDRV. For example, if it resides in C:\POS\ALOHA, share the POS folder as BOOTDRV.



Depending on the version of Windows XP you are using, you may have to enable file sharing before installing the Aloha application software.



If you are using Windows XP Home Edition, you must first perform the following to configure Windows sharing so the Aloha application software setup application can create the required BOOTDRV file share:



Right-click on the drive or folder in which you plan to install the Aloha application software and select Sharing and Security.
If you right-clicked on a drive and not a folder, you may receive a warning about sharing the root folder on a hard drive. Continue past this warning.
The drive or folder properties window is where you enable network file sharing. Click 'If you understand the security risks but want to share files without running the wizard' to enable network file sharing.
Click 'Just enable file sharing' on the Enable File Sharing window and click OK.
Click OK on the drive or folder properties window since you do not need to create a new share name (the Aloha application software setup application creates the BOOTDRV share for you).
Refer to document ID 5976 for more information on configuring Windows logins and shares for the Aloha application software.


If you are using Windows XP Professional and you are part of a workgroup, then Windows enables simple file sharing by default, but you can disable simple file sharing in order to enable user-level file sharing. If you want to use simple file sharing, you must perform the following before installing the Aloha application software:



Right-click on the drive or folder in which you plan to install the Aloha application software and select Sharing and Security.
If you right-clicked on a drive and not a folder, you may receive a warning about sharing the root folder on a hard drive. Continue past this warning.
The drive or folder properties window is where you enable network file sharing. Click 'If you understand the security risks but want to share files without running the wizard' to enable network file sharing.
Click 'Just enable file sharing' on the Enable File Sharing window and click OK.
Click OK on the drive or folder properties window since you do not need to create a new share name (the Aloha application software setup application creates the BOOTDRV share for you).
Refer to document ID 5976 for more information on configuring Windows logins and shares for the Aloha application software.


If you are using Windows XP Professional as part of a workgroup and you want to enable user-level sharing, perform the following:



Open My Computer and select Tools/Folder Options/View. Disable 'Use Simple File Sharing' and click OK.
Refer to document ID 5976 for more information on configuring Windows logins for the Aloha application software.


If you are using Windows XP Professional and you are part of a domain, then Windows enables user-level sharing by default, but you can disable user-level file sharing in order to enable simple file sharing. If you want to enable simple file sharing, you must perform the following before installing the Aloha application software:



Open My Computer and select Tools/Folder Options/View. Enable 'Use Simple File Sharing' and click OK.
Right-click on the drive or folder in which you plan to install the Aloha application software and select Sharing and Security.
If you right-clicked on a drive and not a folder, you may receive a warning about sharing the root folder on a hard drive. Continue past this warning.
The drive or folder properties window is where you enable network file sharing. Click 'If you understand the security risks but want to share files without running the wizard' to enable network file sharing.
Click 'Just enable file sharing' on the Enable File Sharing window and click OK.
Click OK on the drive or folder properties window since you do not need to create a new share name (the Aloha application software setup application creates the BOOTDRV share for you).
Refer to document ID 5976 for more information on configuring Windows logins and shares for the Aloha application software.


If you are using Windows XP Professional, you are part of a domain and you wish to use user-level sharing, then you only need to refer to document ID 5976 for more information on configuring Windows logins for the Aloha application software.



Refer to Microsoft Knowledge Base document Q304040 for more information on Windows XP file sharing.

Display Settings
Set the Color palette to 256 Colors or higher. Aloha Technologies typically uses 16-bit color.



Refer to document ID 6135 for screen resolution settings.



Do not enable a Windows screen saver.

Time Zone & Daylight Savings
For the file server and all terminals to display the correct time and adjust to daylight savings changes properly, the time and date settings must be properly configured in Windows so the file server and each terminal have the same time, date, time zone and daylight savings settings. The time settings need to be the same on all terminals and the file server. If the area observes daylight savings, then you must configure the file server and each terminal to automatically adjust for daylight savings. You can disable automatic daylight savings adjustment if you are in an area that does not recognize daylight savings time (or if you do not want the file server and terminals to automatically adjust for daylight savings), but it needs to be disabled throughout the Aloha application software. You cannot enable daylight savings on one terminal and not on another or enable it on the file server and not the terminals.

Login Name
Refer to document ID 5976 for more information on configuring Windows logins for the Aloha application software.

Processor Performance
By default, Windows XP is configured to assign foreground applications priority processing. This can cause erroneous behavior in background applications, such as Control Server and EDC Server. Aloha Technologies suggests setting the processor priority to background applications.



To configure the processor priority, open the System properties and select Advanced/Performance Options, and select Settings in the Performance section. Select Advanced, and set the performance scheduling to Background Services.

Service Pack
Aloha Technologies recommends installing Windows XP Service Pack 1 after all software has been installed and Windows XP is configured properly.



Reinstall the Service Pack anytime significant changes are made to Windows XP.

Install Aloha Software
Once Windows XP is set up to the standards outlined in this document, use the Aloha Application Software Installation CD to install the Aloha application software. Run ADVANCED.EXE from the Aloha POS CD. The setup program walks you through the rest of the installation. Ensure you have enabled Windows file sharing as explained in the File Sharing section of this document before installing the Aloha application software.



Refer to document ID 6132 for more information on running Control Server and EDC Server as Windows services.



Once the installation is complete, you can edit user access to the BOOTDRV share if you have enabled user-level file sharing.

Set Control Server and EDC Server Login
You may need to adjust the login account used by CTLSVR.EXE (Control Server) and EDCSVR.EXE (EDC Server) on the file server to ensure proper operation with terminals running Windows XP. Refer to ID 6149 for more information.

Extended Information
Improving Performance
For additional performance, consider disabling features you do not plan to use, such as System Restore,

Remote Assistance, QoS Packet Scheduler, and Windows Messenger.

EOD File Copy Errors
If you are experience problems where the End-of-Day (EOD) process fails to copy files, you should perform the following in order to disable write caching for the hard drive in which the Aloha application software resides on the file server:



Open Windows Explorer, right-click on the hard drive in which the Aloha application software is installed, and select Properties.
Select the Hardware tab.
Select the physical drive, and select Properties.
Select the Policies tab.
Clear the 'Enable write caching on the disk' option, and press OK.
 
Thanks Adam!

Does anyone install service pack 2? I ask because I recently built a file server with XP and they very last step I did was install SP2. Then I started getting Security Key Not Found issues.

 
We do not upgrade Windows unless needed after it is in. If it is running Aloha and the Windows Office suite, don't fix what ain't broke. Of course when we build a server we perform all the updates before we load the software. Turn off the windows firewall and enable the guest account with it being a member of administrators will save a lot of networking issue calls.


Bo

Kentucky phone support-
"Mash the Kentrol key and hit scape."
 
We get Dell Optiplex's for FS, and they come with SP2, so no choice really. When it first came out, it was a big no no to use it with aloha, but I feel very comfortable with it. The worst part is networking with win98 terminals, pain in the butt but not terribly difficult. Make sure you turn off the reporting in the security center. One thing I do when networking with other xp or 2000 terminals is to go into local security policy->local policy->security options, under network security:sharing and security model for local accounts, tell the computer to use the classic model (basically using usernames instead of the default guest only). That way only the terminals that have the correct username and password can access the FS. Of course the terminal needs to logon using a username that the FS has as well. Other than that, I find that XP as an FS is quite reliable, and my preferred OS.


ADam
 
AkamaiAloha,

You may want to go to and download the HASP driver version 4.96 or higher to work with XP SP2 and get rid of that Security Key Not Found error. 4.96 gave full support to Win32 XP SP2 on 64-bit extended systems.


I think they are up to version 4.99 now but that will work as well.

The file I use is HASP4_driver_cmdline.zip

One thing to remember though is to do a hinstall -r before putting the new hinstall.exe in the bin. Then extract the hinstall.exe and the haspds_windows.dll into the bin and run hinstall -i. Failure to put the .dll in the bin will make hinstall not work since it is looking for that file.
 
Thanks Adam, Bo, and Rad.... you guys, along with Aloha1, have been a huge help. As always, I appreciate your input and opinions.

Funny you mention the networking thing Adam. I distinctly remember having an issue, that if win98 was on the front of house and XP was on the back, I would end up with networking pains in my butt. I am not sure if the issue was related to "browser lists" (a windows concept) or what, but after the terminals were up for a while, suddenly one would no longer be able to access another. For example, I could go on term1, do a search for term2, and it would find it. But one I tried to access the BOOTDRV, it would say something to the effect of "This terminal is no longer available on the network" blah blah blah. Yet, aloha would be up and running fine. Yet, there were flakey issues that surfaced in this situation, and obviously I knew something wasn't right in Microsoftland. I know that there is an AKB that applies to this situation, but I thought it was more for windows 95 terminals. My guess you guys know the issue I am talking about, and I am not completely sure what you're supposed to do (and at 2am EST, I am too lazy check :) ). Anyway, I found a work around. If you put the Default Gateway as the BOH's IP address on the win98 terms, all will be well. This phantom issue of being able to see other terms on the network... but NOT able to access them... goes away, along with all the other flakely problems.

Not Aloha's recommended solution (and for once, not Aloha's problem :) ), I know... but one that is easy and works none the less.

Thanks again!

 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top