RES 3700 - Incorrect server name in MDSHOSTS.XML

.

If you are seeing this error message in your 3700d.log then either someone has changed the name of your servers hostname or someone changed the name of the server in the pos configurator.

Micros RES relies on the server name remaining unchanged.

Step 1) Find out what your server name should be.
To do this open Services.msc. You will have a service called "sqlSERVERNAME" where servername is the name that your server should be.

Step 2) Next check what your servers name actually is. Open a command prompt and type in "hostname". This will return to you your servers name.

If the servers name is incorrect then change the name back to what you found in step 1. Right click on My Computer -> Properties -> Computer Name tab and click change.

---------------------------------------------

Do you need to change your server name?

There are some reasons why you need to change your servers name whether it be changing your companys name and your server name reflects the old one, moving your server onto a domain etc.

Micros supplies a handy little tool which does all the work for you. This tool is compatible with RES 4.9 and below. Click here to download it.
Email me if the download link stops working.

Usage:

Within the ZIP file you have the following files:
- setname.exe
- setname.cfg
- mfc70.dll
- msvci70.dll
- msvcr70.dll

Copy all 5 files to D:\Micros\Res\Pos\Etc

Note: This tool changes your computer name as well as any necessary registry settings.

Before starting turn your database off from the Micros Control panel.

Run setname.exe and you will be shown the same as the below image.

Enter your new server name in the text box provided and press OK. You will be informed when the program has completed. It shouldn't take too long.

Restart the server.

Once the server is restarted open the Pos Configurator -> Devices -> Network nodes.

Select your server from the list and change the computer name to your new name.
Press the green tick to save.
Reload the database from the Micros Control Panel.

And your done!.


.



.

RES 3700 - How to clear system financial totals from the database.

So for whatever reason you want to clear all of the financial totals from the database. Here is how its done.

Open the Micros Control Panel and bring the system to database level.

 

Open the Micros Pos Configurator -> Totals -> Clear All Totals or you can clear each set of totals individually.

Depending on how many totals you have in the database this can take a few seconds to about 15 minutes.

After it is successfull you will get a popup advising you of this.You will be unable to use the pos configurator untill this has been completed.

After completion you will need to reboot the micros database.

Erasing contents of a Micros WS4, WS4LX, WS5(a)

Sometimes you want to wipe the contents of a workstation for whatever reason. These instructions are identical regardless of workstation and POS type. This is how its done:

On all WS4, WS4LX, WS5 and WS5a workstations there are two drives called CF and DOC.

The DOC is a storage space on the workstation which is not on the Compact Flash card.
In the DOC drive you will have a folder called Utilities and inside this folder there is an executable called WCF.exe. This executable is basically used to reset the workstation back to factory settings.

Once launched you will be given three options:
- Clear Registry Settings
- Erase Compact Flash
- Format Compact Flash

All options are self explanatory. One note however Format Compact Flash automatically performs option 1&2. Once any of the options are selected the workstation shuts down. You will need to press the power button to turn it back on. Once it turns back on you will be requested to install micros again using CAL.

RES 3700 - Log files for Micros RES 3700

3700d.log - Located in D:\Micros\Res\Pos\Etc

The 3700d.log contains the general day to day logs of the micros pos system.

The logs are rotated every day as part of the end of day or whenever the executable "rotatelog.exe" is executed.
Each rotation appends a number to the end of the file name eg. 3700d.log.0
A maximum of 7 days logs is kept at any one time.

The verbosity level of the log file defines how much detail is logged. By default it is at level 0.
To change the verbosity open the micros control panel via the run prompt "cpanel.exe /verbosity" and in the control panel you will have a new verbosity tab where you can set the logging level. See the below screenshot.

 
If you select your Server name and select the verbosity tab you will see a list of modules where you can increase the verbosity level using the slider along the bottom for a particular module.

This becomes very useful if you notice a problem with a certain part of micros and to help diagnose this you increase the verbosity.

NOTE: If the verbosity level is left too high the log files can become very large very fast.


DM.log Located in D:\Micros\Common\Etc

This log contains information from the usage of the Database Manager. ie. backups, backup validation etc.


CLCONTROL_SERVERNAME.log Located in D:\Micros\Res\Pos\Etc

This log contains the logs when the CLCONTROL command line database control program us used.

RES 3700 - Remote reboot of workstations in Micros RES 3700 POS command line

As you may have already noticed in RES 4.x they introduced a reboot feature in the Micros Control Panel which lets you reboot an individual workstation or all of the workstations at once.

What you probably didn't know was that this functionality has always been available since the first Micros 3700 Pos system. It is a command line program called REMOTEREBOOT.exe and is located in D:\Micros\Common\Bin

If you type REMOTEREBOOT /? into the command prompt you get the below user information but simply if you type "remotereboot WS01"  it reboots the workstation called WS01. Simple and useful.

MICROS RES RemoteReboot version 4.1
usage:  RemoteReboot [/?] [-h] [/allclients] [<nodenames>]+

   /? or -h prints this help message.

   /allclients reboots all configured clients. Will not reboot the server.

   Specifying one or more computer nodenames on the command line will cause
      a message to be sent to reboot only those client workstations

RES 3700 - Understanding DBISQL for Micros POS.

DBISQL is a program which is used to query the Micros 3700 POS database.

It can be launched on the micros server by typing DBISQL into the run prompt and pressing OK. See below screenshots.

Micros POS installs usually have then following passwords by default. You may also have been given a DBA password by your micros installer.

Username: custom
Password: custom

or

Username: installer
Password: installer

You may also need to select the ODBC data source name which will be called "Micros" but 99% of the time you wont need to do this. See the image above.

----------------------------------------------

An example of what you expect to be able to see after logging in is shown in the image below.

An example what what an actual query in dbisql looks like is shown in the image below. This query returns the data for all checks in the database.

To search how select, update, inserts and everything to do with SQL works I suggest you google some tutorials so you can get the most out of your micros database.

RES 3700 - Error: XXXX number of checks have not been purged.

This is an error which indicates that old closed checks have not been purged from the database.
Two tables contain check details which need to be purged:

micros.chk_dtl and micros.trans_dtl

Micros 3700 is hard coded to keep check detail for 14 days. If the database fails to purge this data after 14 days it starts to give the "XXXX checks have not been purged" where XXXX is the number of check detail.

There is a stored procedure that should be in the End of Day/Night Audit steps called Purge History. This calls a stored procedure:

micros.sp_purgehistory();

Steps to resolve:

Step 1) Make sure the End of Day is being run at the end of your business date. If it is not being run then it wont be able to run the necessary stored procedure. As part of your end of day there should be a step configured which is a stored procedure called Purge Historical Totals.

Step 2) If the End of Day is being run then something is not working as it should.

Things to check:

a) Make sure you don't have loads of open checks from weeks ago on the system. If you do then close them off. After the end of day runs again it should purge the necessary data.

b) Make sure the purge step is part of the end of day.

Step 3) If still having problems open DBISQL. If you dont know what DBISQL is then click here for a quick tutorial on what it is. 

Run the following query:

Select min(business_date) from micros.trans_dtl

This will return to you a date. If the purge is running correctly this date should be no more than 14 days before the current business date. In your case it may be out by a few days or weeks depending on how long you have been seeing the error message. Make a note of this date.

Run the following in dbisql:

call micros.sp_purgehistory();

Depending on how many days out your purge is this can take from a few seconds up to 10-15 minutes. (Ive seen it take an hour on an old system where the purge didn't run for months.)

After the procedure completes in the result section of dbisql it will say Procedure Completed.

Now run this statement again:

Select min(business_date) from micros.trans_dtl

The date should have changed to a more recent date. Keep running the "call micros.sp_purgehistory();" procedure until the date is to 14 days from the current business date.

You should now find that the errors on your tills have gone.

If your still having problems then contact your micros support as there may be some issues with the micros.chk_dtl or micros.trans_dtl database tables.

Im not going to get into diagnosing these problems here yet. If you believe you have a strong grasp of SQL and are comfortable updating and deleting rows from the SQL database then drop me an email and ill tell you what to look for.

RES 3700 - Error: Waiting on MDSHosts.xml

When ops is starting on all versions of micros workstations it loads a number of different modules.
The essential ones are as follows for correct operation of the workstations.
MDSHosts.xml
MDSServices.xml
MDSPrinters.xml
Ops.exe

You may also find KDS Display loading depending on your setup.

You may find that the Application Loader will stall on any one of these, the most common being MDSHosts.xml.

MDSHosts.xml contains IP address and Hostname information for the server and all workstations so its essential for operation.
On WS4, WS4LX, WS5 model workstations its located on the compact flash drive in cf\micros\etc
On Win32 workstations its located in c:\micros\common\etc.
Same applies for all the .xml files above.

Workstations should be kept up to date automatically with these files and should be downloaded upon installing ops using CAL.

If you find the Application Loader stalling there are a few simple steps you need to take.

Quick Fix: Transfer a copy of the MDSHosts.xml to the workstation. It is located on the server under D:\micros\common\etc and needs to be copied to the workstation. See above for the correct directory.

Long Term Fix:

Step 1) Make sure the MDSHosts.xml has a good copy on the server. It should be located in D:\micros\common\etc
Check the last modified date. It should be fairly recent ie. a few days. Reload the database via the Micros Control Panel (reload not restart). If the modified date has not updated and the workstation still not starting then proceed to step 2.

Step 2) Force the database to create a new copy. Open services.msc and restart the following services:

Micros Distributed Services Manager

Micros DB Update Service

Step 3) Reload the database via the Micros Control Panel. ( reload not restart ). The last modified date of the file should have updated to the current date/time.

RES 3700 - Low Disk Space Common Causes.

From time to time it is possible that the micros drives can run out of space. Below i will list the usual suspects.

Database backups:

If your backing up the micros database on the server you should be running database validation. If the validation fails it will create a .bad extension backup in the "%Database Dir%\micros\database\data" directory where %Database Dir%  is the drive the database is stored on.

For reasons i dont know why if a .bad file is created the archived backups will no longer rotate and it will store backups in the "%Database Dir%\micros\database\data\archives" until the hard  drive runs out of space.

Solution: Delete the .bad file and delete any unnecessary backups in the archives directory.

-----------------------------------------------------------------

3700d.log Verbosity:

In the D:\Micros\Res\Pos\Etc directory there are 7 days worth of 3700d.log files.
If the verbosity is turned up high in the logs and left like that it can eat up disk space very quickly.
To change the verbosity open the Micros Control panel via the command line.

cpanel.exe /verbosity

The Micros Control Panel will now open with a verbosity tab where you can change the verbosity for the services and workstations between 0 and 10. Normal use should all be 0.

-------------------------------------------------------------------

Database Log File size:

All RES 3700 databases have a file called micros.log kept in the "%Database Dir%\micros\database\data" directory along with the micros.db which is the database.

The micros.log file is essential for the database to run but on occasion this file has been known to vastly increase in size into the gigabytes. Usually they are less than a few meg if not less than a meg.

Version 3.2 and below:

Step 1) Stop the database.

Step 2) Start -> Run and type in "scview" without the quotes and press ok.

Step 3) Select utilities and select "Change log file information". You may need to add the adaptive server anywhere plugin to get these options.

Step 4) Browse to the micros.db file and press next.

Step 5) Use all the default options here except the step where it asks you to create a mirror log file, here select "no change"

Step 6) Tick the box to delete the old log file information and press finish.

Step 7) Once you press finish you will be given a summary of your settings, just press ok to this.

Step 8) Open a command prompt and change the directory to the micros database directory which contains the micros.db file and execute the following command.

dbsrv6.exe micros.db -f

The SQL adaptive server anywhere program should have opened and now shrank down to the system tray. Double click on the icon and select shutdown.

Now start the database via the Micros Control Panel and shazam you should have a started database and a brand new small micros.log file.

Version 4.0 and above:

Thankfully much easier than 3.2 and much less frequently needed.

Step 1) Stop the database

Step 2) Delete the micros.log file

Step 3) Run the following command from the run prompt where D:\ is the drive of your database. You might notice something flash up for a split second but will most likely go unnoticed. (Capital F is important)

DM.exe -F D:\micros\database\data\micros.db

Step 4) Start the database via Micros Control Panel, you should now have a new micros.log file.


.

RES 3700 - Error: No communication with autosequence pc.

The service Autoseqserv.exe is responsible for managing scheduled autosequences as well as allowing autosequences such as end of shift reports,  to be executed from the pos operations.
If this service is frozen or simply not running you will get an error indicating that there was a failure communicating with the autosequence pc.
A lot of the time if the service is frozen you will simply have the pos operations hang for a few minutes before the error displays, if the service is not running you should get the error almost instantly.

RES 3.2 and below:
The autosequence service is located in the Micros Control Panel and can be turned on or off.

RES 4.0 and above
The autosequence service is located in windows services and is called "Micros Autosequence Service". If it is stopped start it, if it is started then restart it.

If you are unable to restart the service you will need to kill the executable via task manager or 3rd party program  such as pskill.exe which can be downloaded from microsoft.com.

RES 3700 - System Closed

.
System Closed is an error that you will get on the micros workstations when the system is set to "Back of House".

To resolve this open the Micros Control Panel. Start -> Programs -> Micros Applications -> Micros Control Panel.

Select Restaurant. On the right hand side you should have the option to press "Front of House" and then press ok.

All should be ok now.

RES 3700 - Licence is in Grace Period or has Expired

Micros RES requires a licence in order to operate.

If you dont have a licence you can put the product into Demo mode where it will operate with a reduced capacity.
To put it into demo mode "Start -> Programs -> Micros Applications -> Utilities -> Licence Manager" and enable DEMO.

If you have a licence but its still reporting as in grace period or has expired follow the below steps.

Step 1) Open the licence manager. See above. Make sure its not in demo mode.

Step 2) Open the Services list by typing services.msc into the run prompt. Restart the Micros Distributed Services Manager. If it fails to restart or freezes you will need to kill the process from the taskmanager. The service name is dsm.exe. Once killed start it from the services list.
Open the licence manager and press reload. If the licence now says "Key Present" you should be good to go.
NOTE: This problem is very frequent in 4.1 HF3. Look into upgrading if you have this version.

Step 3) If its still not working chances are the licence key is unplugged. It is a physical USB Key plugged into a USB port on the server. Very old micros versions will have a serial licence key plugged into the LPT1 port.

If you have a USB, reseat they key and Perform step 2. If you have a serial key reseat the key and reboot the server.

Step 4) If you cant find a USB licence key plugged into the server then contact your Micros Dealer. If you are part of a large chain you might have a MAL licence which is a software licence and you will need to contact your support.

RES 3700 - Error: No communication with Database server, Enter Stand Alone Mode

.

Stand Alone Mode - is a status where the tills can operate by themselves without any communication with the micros server. All checks will be stored on the workstation and any checks created on the other workstations will not be accessible from anywhere except the workstation it was created on.

A requirement for this to be successful in closing off checks and giving customer receipts is to have payment types designed for Stand alone mode.  These payment types are usually denoted by "O/L" before the payment type.OL = Off Line.

This is only a requirement if the Micros is integrated with a PMS system as to prevent the offline still attempting to communicate with the PMS system.

Troubleshooting

Step 1) Make sure the Micros server is turned on.

Step 2) Make sure the database is running. Open the Micros Control Panel "Start -> Programs -> Micros Applications -> Micros Control Panel". Select Restaurant and make sure that the system is set to "Front Of House".

Step 3) If the system is set to Front of House next thing to check is if the workstations are showing as green arrows in the control panel. If all the workstations are Red arrows then the problem is with the network communication between the server and the workstations.
If you dont see any workstations green or red then select View -> Show All Clients.
You should now be able to see whether they are Green or Red.

Step 4) Check the free diskspace on the database drive. If the drive has no space the system wont work.

Step 5) If all of the above is ok then your next step is to check the status of the MICROS MDS HTTP SERVICE.
Open services list by typing Services.msc into the run prompt. Scroll down to the Micros mds http service and make sure its started. After it is started reload the database via the control panel. This service is required for communication between the workstations and the database.

Step 6) If all above has failed then restarting the server couldnt hurt.

Step 7) Further investigation into the logs would be needed.

.

RES 3700 - Error: Timeout while sending message, check fo server, ifc or cables.

.

This error is received when Micros point of sale is interfaced with another application. Most common application that micros interfaces with would be the Opera Property Management System. This application is used for managing the Hotel side of things.

Below are a list of things that you need to check in order to resolve this issue.

Step 1) Make sure the Micros Interface service is running. This can be in two locations depending on the version of RES 3700 installed.

Version 3700 3.2 and below

In 3.2 and below the interface service is located in the Micros Control panel. Open the control panel "Start -> Programs -> Micros Applications -> Micros Control Panel" and make sure there is a green tick beside the interface service.

Version 4.0 and above

In 4.0 and above all micros services except the "SQL Database Service" were moved from the Micros Control Panel to the windows services list. This services list can be accessed by typing Services.msc into the run prompt. Make sure the "Micros Interface Service" is started.

Step 2) Make sure the interface is running. The interface is generally located on another server/pc which is not the Micros server. This program acts as the middle man between Micros and the end product for example Opera PMS.

Step 3) Once you have confirmed that Step 1 and Step 2 are ok the next thing is making sure there is network communication between Micros and the Interface pc. Im not going to get into COM connections and am only going to focus on TCPIP connections.

Open the "Pos Configurator -> Devices -> Interfaces"  and select the interface which you are having trouble with. Select the interface tab on the right and you will see an ip address and port number. Make a note of these.

Open a command prompt and type in "Ping x.x.x.x" where x.x.x.x is the ip address without the quotes and press enter. If you get a reply then the network connection is active.

Next is to test the port number. Open a command prompt and type "telnet x.x.x.x yyyy" where x.x.x.x is the ip address and yyyy is the port number and press enter. If the command prompt goes blank with the blinking cursor in the top left then everything is ok and working, if it does not connect then there is a problem with the port. Consult the supplier of the interface for more info.

Step 4) If step 3 is successful then the problem is going to be with the end product eg Opera or with the connection between the Interface pc and the Opera server.

RES 3700 - Error : Check Detail Read Failed

 .

The error "Check Detail Read Failed" while trying to open a check/table on the micros RES 3700 point of sale system. This error is present is all versions of RES but occurs much less frequently since RES 4.0


This error is an indication that the check has become unreadable in the database. It can occur if the check is being accessed during a power failure or some other interruption to the operation of the micros system.


These checks are unrecoverable and can only be closed in the database.

To proceed you will need to know the check number which is currently causing the error.


Step 1) On the Micros POS server open DBISQL. To do this press Start -> Run -> Type "dbisql" without the quotes.


Step 2) Enter the username and password:

Username: custom

Password: custom

or

Username: installer

Password: installer

Step 3) Type the following command and replace XXXX with your check number and execute:

Select chk_seq, chk_num, chk_open from micros.chk_dtl where chk_num = XXXX;

chk_seq = Check Sequence number is a unique number

chk_num = Four digit check number used to identify a transaction.

chk_open = True or False. True means the check is open, False means its closed.


Step 4)  Make a note of the number in the chk_seq column and type in the following command and replace XXXXXX with the chk_seq number and execute:

call micros.sp_forcechkclose(XXXXXX);

The check should now be closed.

.