Error checking is extremely important to insure the integrity of your accounting
information. It is provided in ICommander in several different ways.
ICOBOL Runtime Error Checking
The ICOBOL Runtime includes such things as validating that only numbers are entered in numeric fields, files needed by a program are available and accessible by the user, and whether all data files are reliable. The File Reliability Checking is very important. ICOBOL checks each file for any type of corruption when it is accessed in a mode that allows changes. If any damage is found, processing halts immediately with an ICommander File Access Error Screen blinking at the user with full details about the filename, the path to it, the date and time, the menu location and the File Status and Exception Status Codes detected by ICOBOL that resulted in the halt. The Status Codes also have the full description of what they mean.ICOBOL also takes a very logical approach to file integrity to allow for power outages or any form of system crash (hopefully your battery backup prevents these but there is always a risk). Whenever a file is opened in a mode where it may be changed, ICOBOL flags the file as being corrupt. Upon closing the file, that flag is cleared. If the system crashes for any reason, any files that were open in a subject to change mode will then be flagged as corrupt. There IS a risk that one or more may actually be corrupt but this approach forces you to run an ICOBOL Function from the ICommander General Utilities Menus to check the integrity of those files before you can proceed with processing. If a file is reliable, the flag will be cleared. If one or more are not, you may then use ICOBOL Functions on the ICommander Management Utilities Menu to rebuild the damaged file.
ICommander Error Checking and Logging
As noted above, ICommander will generate a File Access Error Screen in the event of any type of serious error condition detected by the ICOBOL Runtime. The information provided on these screens enable rapid resolution of the problem. We had always encouraged users to do a Print Screen of these so they were available for ICommander Support Staff to assist in fixing the problem.The panic that occurs when there is an error often resulted in users forgetting about doing a Print Screen. ICommander now immediately logs a copy of the File Access Error Screen and any other significant error messages into an icerrors file for each user and across the entire system. These are available via the ICommander Print Utility for any created today and in a continuing log of all such automatic error print screens since the log file was last cleared.
Users who know the systems well and work very rapidly have been known to ignore an important error message, if they are able to continue processing. Doing so often will result in something being detected later on that relates to the error message that was ignored. The ability to explore all such stored messages becomes invaluable for problem resolution in that case.
ICommander entry programs validate entries beyond what is possible with the ICOBOL Runtime as it does not know the nature of what is being entered. This includes validating any codes entered to the files in which they are defined or to an ICommander table of valid entries. All G/L Account Numbers are validated to the Chart of Accounts and any entry programs where a total is being distributed usually does not allow exiting the program until every balance check succeeds. ALL posting programs will not allow posting until every balance check succeeds.
All transaction entry programs have various Edit Lists available for users to review their entries before updating to the permanent data and history files. Every posting routine first spools one or more posting registers reports so there is a hardcopy trail of all updates. Since the advent of the ICommander Automatic Archiving ability, we try to get all users to flag all Posting Registers to be automatically archived (there is a function that enables flagging all such programs when ICommander is initially implemented). The Automatically Archived Reports are readily available from the ICommander General Utilities for viewing or retrieving a copy back into the ICommander Print Utility for later printing.
Even though Posting Registers are typically archived, they will show up in the ICommander Print Utility (flagged as having been archived). This makes it simple for users to access, to view and/or print only total pages or particular parts of the report where a current printout is useful. Once they have the information they need, the Posting Registers may be safely deleted as they continue to exist in the Archive Files.
ICommander posting routines create the Posting Registers before posting has actually occurred. This is because the programs that create these reports also check for many types of possible error conditions. If an error is encountered, the user may then access the spooled register to locate it and resolve it. The Posting Registers may then be deleted as restarting the posting after the error condition is fixed will recreate them.
The ICommander posting programs are designed to record each update to a data or history file as it occurs. This is done in order to allow for the potential of some type of error during posting. Combined with the information provided by ICommander when an error does occur, this enables restarting even the most complex posting routine where it left off once the error condition has been resolved.
Some complex posting routines may involve several separate programs. When that is the case, ICommander will know what program was involved when the error occurred and may not let the posting be restarted from the posting menu choice due to some routines already having been completed. If it is safe to restart the posting in the program that had the error, the applicable program name will be displayed. The ICommander Menu System allows execution of a program by program name (for users authorized to do so) and that is how you get the posting restarted and completed. If an error is considered fairly critical, you may be prompted to contact ICommander Support before continuing. This would be the case when it is important that other impacts of the original error be evaluated before proceeding.
Logged Two Ways
The logging of ICommander Error Screens to the icerrors file is one of two ways in which ICommander logs errors. The other is via the System-Wide Log of all events. The Event Log will always have a trail of all logons and logoffs. The extent of user activity beyond that is optional (based on your decisions when ICommander is implemented) EXCEPT as it relates to any type of error. The event log will always record any type of error condition, even a number that do not result in an ICommander Error Screen being generated.
The Event Log may be reviewed periodically and analyzed by User, Company, Error
Code, etc.