The most common recurring support issue with the OSAS accounting software is related to corrupted data files.  Fortunately, this problem is usually very easy to fix.  Data files can become corrupted by one of several events:


*  The server is acting up

*  The network wiring or hub is acting up

*  The power goes off unexpectedly (at either the workstation or the server)

*  A user does not properly exit the OSAS system or shutdown Windows properly


Most often, the user has a sense that something is wrong and a file has become corrupted.  This can be because they were at their computer when the power went out, or someone in the next room unexpectedly shutdown the server without notifying everyone.  Sometimes, however, it is a mystery.  This can happen on a networked system because several people may be doing data entry into the same file.  One user may cause a problem, but then all users of that file will experience a problem with data entry.


Corrupted data files do not repair themselves.  In fact, what starts as a relatively easy problem to fix, can get very complicated if you ignore the warning signs of corruption and proceed to POST using data files that have some corruption hidden in them.  When you perform a POST and one or more of your data files is corrupted, it is a very good possibility that the POST will hang-up or freeze in the middle of the process, this in turn will cause several more files to become corrupted.  In this way, corruption in one file leads to corruption in several more files (not to mention the complications of a post that is only partially completed).  YOU SHOULD NEVER TRY TO POST IF YOU SUSPECT CORRUPTION IN YOUR DATA FILES!


If, while doing data entry, you experience unexpected power interruptions or lock-ups in Windows that prevent you from properly exiting your system, you should assume the data file(s) you were in are corrupted and immediately perform a rebuild as explained below.  In fact, anytime you suspect a file has been corrupted, perform the rebuild steps – REBUILD NEVER DOES ANY HARM.


To perform a rebuild go to Resource Manager, Data File Maintenance, File Rebuild/Verify.  The program will ask you for the file name.  Most files within OSAS take the form AABBx where:

          -the first two characters are the application

          -the next two characters denote the specific file

          -the 5th –7th characters are the company ID (note: many companies use a single number or letter)


Common Data Files

Here is a list by application of the common data files that may need to be rebuilt.  Be sure to substitute your company ID at the end of the file name in place of the x.


Time Cards during entry of data

XOTRx                    Daily Work Time Cards (unposted transactions)

                             (See special note below about this file)


Time Cards – Not often corrupted

XOEMx                   Employee Master File

XOOPx                   Operations Master File

XOHIx                    Time Card History File used for special reports

                             (can take a while to rebuild)


Accounts Receivable during transaction entry

ARTHx                    Transactions – header records

ARTDx                    Transactions – detail records

ARCTx                    Transaction – control record


Accounts Receivable/Sales Order – Not often corrupted

ARCUx                    Customer File

ARINx                     Open Invoice File

ARHIx                     Detailed History File (can take a while to rebuild)


Sales Order during transaction entry

SOTHx                    Transactions – header records

SOTDx                    Transactions – detail records

ARCTx                    Transaction – control records


Accounts Payable during transaction entry

APTHx                    Transactions – header records

APTDx                    Transactions – detail records

APCTx                    Transaction – control records


General Ledger

GLJRx                    Journal Transactions (posted and unposted together)

GLMAx                   GL Master Chart of Accounts


In the Resource Manager


*--------------------------- File Rebuild/Verify -----------------------------*

|                                                                             |

|  File to Rebuild/Verify: XOTR1                                              |

|                                                                             |


|                                                                             |

|                                                                             |

|         All keys found in all chains                                        |

|                                                                             |

|         Proceed with reconstruct anyway? (Y/N)  N                           |

|                                                                             |

|                                                                             |


|                                                                             |

*- Company 1 -----------------------------------------------------------------*


After you enter the file name, you will see a spinning prompt toward the bottom of the screen.  This indicates the program is scanning your data file.  The program will also show you the progress as it scans the Key Chains.  (A key chain is another name for an index of the data file or a way of sorting the data.)  You can ignore any messages that might flash across the screen as it is scanning.  We want to see the results at the end of the scan.


The number of key chains varies from file to file.  If the program finds everything that it expects, then you will get the message:


          All Keys found in all chains

          Proceed with reconstruct anyway?


If you are rebuilding a Daily Work Transaction file, then I would always say Yes to rebuild anyway.  This is especially true of the AR, SO, and AP files – they often report that all keys are found, yet really need to be rebuilt.  If you are rebuilding a history file, then it is likely the history file is OK and you do not need to rebuild it.  When in doubt, rebuild anyway (it never hurts).


If corruption is identified in the file, then the program will display the key chains and the corresponding number of keys found in each chain as in the example below.


*--------------------------- File Rebuild/Verify -----------------------------*

|                                                                             |

|  File to Rebuild/Verify: XOHI1                                              |

|                                                                             |


|                   Reported Active Keys =  7208                              |

|                                                                             |

|                   Key Number: 0    Found: 7176                              |

|                   Key Number: 1    Found: 6534                              |

|                   Key Number: 2    Found: 6534                              |

|                   Key Number: 3    Found: 6708                              |

|                   Key Number: 4    Found: 6621                              |

|                                                                             |

|                   Key to Rebuild:   0                                       |

|                                                                             |

|                                                                             |


|                                                                             |

*- Company 1 -------------- Quick ----------------------------------- Verify -*


When the program suggests a key to rebuild, accept whatever key it suggests simply by pressing <enter>.  It will always pick the key number with the largest number of keys found.  The program will then proceed with recovering the records.  When the recovery is completed, you will get the prompt:


Replace original file with rebuilt file? (Y/N) Y


Say YES to replace the old file with the newly rebuilt file.  Sometimes the rebuild will not be able to recover all the records it was trying to recover and the program will tell you so.  There is nothing to do but accept this and replace the original file.


That’s it.  The file is rebuilt.  You can come back in and rebuild another file if necessary.  When rebuilding transaction files the whole process should generally only take a few minutes.  If you need to rebuild a history file, however, the process can take a couple of hours depending on your system speed and how large the file is (some history files contains hundreds of thousands of records).


Rebuilding a file allows OSAS to work with the file in the normal way.  However, rebuilding a file doesn’t mean that all records have been recovered.  You may have lost some data.  It pays to note from the rebuild screen the number of reported active records near the top, and the number of keys found in the chain the program has chosen to rebuild.  This will often give you a good idea of how much (if any) data you may lose.  You can always use the associated print program for the application to proof your data after you have finished the rebuild.


For Daily Work transaction files, if you lost a few transactions, you can always re-enter them.  Most often you only lose one or two transactions.  Keep in mind that if a data file becomes severely corrupted, or the data file is a master file (like the GL Journal file or the Employee master file) your best recourse may be to restore all of your files from a backup.


The above list is not an all encompassing list of every file that could become corrupted.  The above list is the most common files that get damaged.  If you want a complete list of all of your data files, you can use the Resource Manager, Reports, Data File Allocation Report.  (Hint: say NO to Report Writer Data Files).  This list is a helpful list as it also shows you how big your files are.


Remember, you can always perform the rebuild without having to call us for support.  The rebuild does not change an otherwise healthy file. 


Note for version 6.1x Users

In OSAS version 6.1 (installations done since January, 2002), the rebuild process is a little easier.  The program really works the same way, but it doesn’t ask you all of the prompts, it makes certain decisions for you.  So don’t be surprised if you enter the file name, and the system then does it’s thing and simply tells you when the rebuild is complete.

Special Note for Time Card Transactions

The XOTRx file is a special case.  Every time you rebuild this file, you should perform one additional step.  The rebuild process often leaves this file will one garbage record that boils up to the front of the file after the rebuild.  If this garbage record exists, it needs to be manually removed.


The first record in the file should have a key of ‘ ENTRY’.  To check if a garbage record is in the XOTRx file, use the Resource Manager, Data File Maintenance, Purge Data Records.  This option is right below the Rebuild function on the Resource Manager, Data File Maintenance menu, so you can do it immediately after rebuilding the file.  You will enter the screen as below:


*--------------------------- Purge Data Records ------------------------------*

|                                                                             |

|     Filename     XOTR1                                                      |

|     Description  (description not available)                                |

|                                                                             |

|     File Type    Mkeyed                                                     |

|     Logical Key Size                  Bytes per record            128       |

|     Number of records                 Active keys                  49       |

|                                       Deleted keys                          |

|                                                                             |

|     [1:1:6],[2:1:6]+[9:1:7]+[1:1:6],[3:1:6]+[9:1:7],[4:1:8]+[9:1:7],[5:     |

|     1:8]+[9:1:7],[9:1:7]+[2:1:6]                                            |

|                                                                             |

|                                                                             |

|                                                                             |

|                                                                             |

|     Key Chain    00                                                         |

|     Starting Key                                                            |

|                                                                             |

|                                                                             |

*- Verification --------------------------------------------------------------*

|                              Press F3 to delete                             |

|                                 Key = ' ENTRY'                              |



After you enter the file name, the program will skip down to the key chain.  Accept key chain 00 by pressing the <enter> key.  Skip the starting key by pressing <enter>.


The program will display a message at the bottom of the screen and show the Key =.  The first record that comes up should have a Key = ‘ ENTRY’ (as shown above) or ‘000001’.  If the key is anything other than ‘ ENTRY’ or ‘000001’ , then press the F3 key ONCE.  The program will display the next key.  It should say ‘ ENTRY’ or ‘000001’ .  If it does not, press the F3 one more time.  Notice that when you press the F3 key once, a new key shows at the bottom of the screen.


When the KEY = ‘ ENTRY’ then you can press the F7 to exit (do NOT press F3).  A key like ‘000001’ or ‘000002’ is also acceptable.  You should never need to delete more than one or two records.


You may find that the first record is ‘ ENTRY’.  In this case you never need to use F3 and can simply press F7 to exit.  There is no way of knowing if a garbage record will be there after a rebuild.  Half the time it will and half the time it won’t.  Although uncommon, it is possible that there will be no KEY = ‘ ENTRY’.  So if you see a KEY = ‘000001’ or ‘000002’, then consider yourself done and use F7 to exit.


If you accidentally delete the ‘ ENTRY’ key or any other records, it is not a big deal, the system will work fine.  Simply proof your transactions and add any missing entries.  In figuring what you may have lost, consider that entry ‘000001’ is the first transaction you entered for this pay period.