If an rpc function is called, there may be additional errors besides regular SNNS errors, such as the call of the DeletePattern function without a defined pattern in the network. Because rpcgen is not generating error code within the rpc routines the result of these functions has to be checked for errors. Since these routines return a NULL value in case of an error, the return value can be checked for NULL and the system can then call an error routine, which determines the exact cause of the error. The rpc library provides such an error routine. Because the rpc mechanism can not determine if there is a net-adapter malfunction or if one of the cables is defect, the rpc mechanism only determines that there is no response from anyone within a given time interval. The error cause, delivered by the error function is not that an adapter card is defect, but that the time interval was exceeded (time-out error). This is the most common type of error and the communication module tries to detect the error with the help of the graphical user-interface.
To accomplish such a task, the communication module remembers if the last inquiry was performed synchronously or asynchronously. If the inquiry was asynchronous the probable cause is that the server is not ready for a new task, because it has to finish the current one. Therefore the simulator kernel reports to the graphical user-interface as soon as it has finished its task. This enables the communication module to update all status informations about the simulator kernel. The user will be informed about an error, and if available what kind of error, over a `pop up' window.
Due to the separation of the graphical user-interface and the simulator kernel, the error tolerance has increased. If there is for example an error in the graphical user-interface, only the interface will be terminated and after a new start of the graphical user-interface and its linking to the simulator kernel, the user is able to proceed exactly where the error occured.
If an error occurs in the kernel the situation is less complicated. In that case simply a new net has to be started, since the communication module intercepts all maskable signals and saves the current net before it ends its operation correctly.
This kind of independence can be used to train multiple nets in parallel. All that has to be done is to load multiple nets with multiple simulator kernels and to start the training process asynchronously with the desired parameters. Now the graphical user-interface can be terminated, while the simulator kernel trains the nets. It is possible to interrupt the training and to evaluate the current state of the training process with the graphical user-interface. After that, the training can be resumed. In case the simulator kernel has already finished training the net it will wait a given period of time before it saves the net and ends its operations. In contrast to the batch version of SNNS, snnsbat, it is possible to select all actions of the kernel from a menu and to evaluate the current training, e.g. the current epochs and error rate.